profile
viewpoint

emscripten-core/emscripten 19665

Emscripten: An LLVM-to-WebAssembly Compiler

kripken/ammo.js 2374

Direct port of the Bullet physics engine to JavaScript using Emscripten

asm-js/validator 1774

A reference validator for asm.js.

emscripten-core/emsdk 1415

Emscripten SDK

kripken/BananaBread 1165

BananaBread is a C++ 3D game engine that runs on the web using JavaScript+WebGL+HTML

kripken/box2d.js 1030

Port of Box2D to JavaScript using Emscripten

daurnimator/lua.vm.js 804

The project is superceded by Fengari. See https://fengari.io/

brson/miri 202

An experimental compiler from Rust to WebAssembly (inactive - do not use)

emscripten-core/emscripten-fastcomp 171

LLVM plus Emscripten's asm.js backend

AssemblyScript/binaryen.js 166

A buildbot for binaryen.js, a port of Binaryen to the Web, with TypeScript support.

push eventemscripten-core/emscripten

ShrekShao

commit sha 0e1343707f1937efab8324466a637752e665e164

Add defines for webgl2_ext.h (#12373) Reported by Skia, adding these defines could help them check in code using latest features without waiting which lands in latest.

view details

push time in 2 hours

PR merged emscripten-core/emscripten

Reviewers
Add defines for webgl2_ext.h

Reported by Skia, adding these defines could help them check in code using latest feature without waiting which lands in latest.

This should only impact user including webgl2_ext.h and should have no side effect.

+9 -0

0 comment

1 changed file

shrekshao

pr closed time in 2 hours

push eventemscripten-core/emscripten

Alon Zakai

commit sha 5609689d9f175235149fe3589a3d0754665d9dcf

metadce testing: measure wasm sizes with the names section (#12375) This will make us not be sensitive to changes to the names section, which binaryen is now adding to (WebAssembly/binaryen#3162). We don't want to measure that debug info, our interest is in production code sizes, so this is more representative anyhow.

view details

push time in 3 hours

delete branch emscripten-core/emscripten

delete branch : meta

delete time in 3 hours

PR merged emscripten-core/emscripten

metadce testing: measure wasm sizes without the names section

This will make us not be sensitive to changes to the names section, which binaryen is now adding to (https://github.com/WebAssembly/binaryen/pull/3162).

We don't want to measure that debug info, our interest is in production code sizes, so this is more representative anyhow.

+23 -20

1 comment

1 changed file

kripken

pr closed time in 3 hours

pull request commentemscripten-core/emscripten

metadce testing: measure wasm sizes without the names section

TBRing to unbreak binaryen roll. If this direction doesn't look good we can revert and do something else later.

kripken

comment created time in 3 hours

PR opened emscripten-core/emscripten

metadce testing: measure wasm sizes with the names section

This will make us not sensitive to changes to the names section, which binaryen is now adding to. We don't want to measure that debug info anyhow, our interest is in production code sizes, so this is more representative anyhow.

+23 -20

0 comment

1 changed file

pr created time in 4 hours

create barnchemscripten-core/emscripten

branch : meta

created branch time in 4 hours

Pull request review commentemscripten-core/emscripten

Simplify handling of exported native globals (namedGlobals)

 def create_fp_accessors(metadata):   def create_named_globals(metadata):-  if not shared.Settings.RELOCATABLE:-    named_globals = []-    for k, v in metadata['namedGlobals'].items():+  named_globals = []+  for k, v in metadata['namedGlobals'].items():+    v = int(v)+    if shared.Settings.RELOCATABLE:+      v += shared.Settings.GLOBAL_BASE+    elif k == '__data_end':       # We keep __data_end alive internally so that wasm-emscripten-finalize knows where the       # static data region ends.  Don't export this to JS like other user-exported global       # address.-      if k not in ['__data_end']:-        named_globals.append("Module['_%s'] = %s;" % (k, v))-    return '\n'.join(named_globals)--  elements = ',\n  '.join('"' + k + '": ' + str(v) for k, v in metadata['namedGlobals'].items())-  named_globals = '''-var NAMED_GLOBALS = {-  %s-};-for (var named in NAMED_GLOBALS) {-  Module['_' + named] = %s + NAMED_GLOBALS[named];-}-Module['NAMED_GLOBALS'] = NAMED_GLOBALS;-''' % (elements, shared.Settings.GLOBAL_BASE)--  # wasm side modules are pure wasm, and cannot create their g$..() methods, so we help them out-  # TODO: this works if we are the main module, but if the supplying module is later, it won't, so-  #       we'll need another solution for that. one option is to scan the module imports, if/when-  #       wasm supports that, then the loader can do this.-  named_globals += '''-for (var named in NAMED_GLOBALS) {-  (function(named) {-    var addr = Module['_' + named];-    Module['g$_' + named] = function() { return addr };-  })(named);+      continue+    mangled = asmjs_mangle(k)+    if shared.Settings.MINIMAL_RUNTIME:+      named_globals.append("var %s = %s;" % (mangled, v))+    else:+      named_globals.append("var %s = Module['%s'] = %s;" % (mangled, mangled, v))

It does currently. So if this code path is for that, then sgtm.

sbc100

comment created time in 4 hours

PullRequestReviewEvent

Pull request review commentemscripten-core/emscripten

GL tracing: read .length so we always have the right number of arguments.

 var LibraryGL = { #endif  #if TRACE_WEBGL_CALLS-    webGLFunctionLengths: { 'getContextAttributes': 0, 'isContextLost': 0, 'getSupportedExtensions': 0, 'createBuffer': 0, 'createFramebuffer': 0, 'createProgram': 0, 'createRenderbuffer': 0, 'createTexture': 0, 'finish': 0, 'flush': 0, 'getError': 0, 'createVertexArray': 0, 'createQuery': 0, 'createSampler': 0, 'createTransformFeedback': 0, 'endTransformFeedback': 0, 'pauseTransformFeedback': 0, 'resumeTransformFeedback': 0, 'commit': 0,-      'getExtension': 1, 'activeTexture': 1, 'blendEquation': 1, 'checkFramebufferStatus': 1, 'clear': 1, 'clearDepth': 1, 'clearStencil': 1, 'compileShader': 1, 'createShader': 1, 'cullFace': 1, 'deleteBuffer': 1, 'deleteFramebuffer': 1, 'deleteProgram': 1, 'deleteRenderbuffer': 1, 'deleteShader': 1, 'deleteTexture': 1, 'depthFunc': 1, 'depthMask': 1, 'disable': 1, 'disableVertexAttribArray': 1, 'enable': 1, 'enableVertexAttribArray': 1, 'frontFace': 1, 'generateMipmap': 1, 'getAttachedShaders': 1, 'getParameter': 1, 'getProgramInfoLog': 1, 'getShaderInfoLog': 1, 'getShaderSource': 1, 'isBuffer': 1, 'isEnabled': 1, 'isFramebuffer': 1, 'isProgram': 1, 'isRenderbuffer': 1, 'isShader': 1, 'isTexture': 1, 'lineWidth': 1, 'linkProgram': 1, 'stencilMask': 1, 'useProgram': 1, 'validateProgram': 1, 'deleteQuery': 1, 'isQuery': 1, 'deleteVertexArray': 1, 'bindVertexArray': 1, 'isVertexArray': 1, 'drawBuffers': 1, 'readBuffer': 1, 'endQuery': 1, 'deleteSampler': 1, 'isSampler': 1, 'isSync': 1, 'deleteSync': 1, 'deleteTransformFeedback': 1, 'isTransformFeedback': 1, 'beginTransformFeedback': 1,-      'attachShader': 2, 'bindBuffer': 2, 'bindFramebuffer': 2, 'bindRenderbuffer': 2, 'bindTexture': 2, 'blendEquationSeparate': 2, 'blendFunc': 2, 'depthRange': 2, 'detachShader': 2, 'getActiveAttrib': 2, 'getActiveUniform': 2, 'getAttribLocation': 2, 'getBufferParameter': 2, 'getProgramParameter': 2, 'getRenderbufferParameter': 2, 'getShaderParameter': 2, 'getShaderPrecisionFormat': 2, 'getTexParameter': 2, 'getUniform': 2, 'getUniformLocation': 2, 'getVertexAttrib': 2, 'getVertexAttribOffset': 2, 'hint': 2, 'pixelStorei': 2, 'polygonOffset': 2, 'sampleCoverage': 2, 'shaderSource': 2, 'stencilMaskSeparate': 2, 'uniform1f': 2, 'uniform1fv': 2, 'uniform1i': 2, 'uniform1iv': 2, 'uniform2fv': 2, 'uniform2iv': 2, 'uniform3fv': 2, 'uniform3iv': 2, 'uniform4fv': 2, 'uniform4iv': 2, 'vertexAttrib1f': 2, 'vertexAttrib1fv': 2, 'vertexAttrib2fv': 2, 'vertexAttrib3fv': 2, 'vertexAttrib4fv': 2, 'vertexAttribDivisor': 2, 'beginQuery': 2, 'invalidateFramebuffer': 2, 'getFragDataLocation': 2, 'uniform1ui': 2, 'uniform1uiv': 2, 'uniform2uiv': 2, 'uniform3uiv': 2, 'uniform4uiv': 2, 'vertexAttribI4iv': 2, 'vertexAttribI4uiv': 2, 'getQuery': 2, 'getQueryParameter': 2, 'bindSampler': 2, 'getSamplerParameter': 2, 'fenceSync': 2, 'getSyncParameter': 2, 'bindTransformFeedback': 2, 'getTransformFeedbackVarying': 2, 'getIndexedParameter': 2, 'getUniformIndices': 2, 'getUniformBlockIndex': 2, 'getActiveUniformBlockName': 2,-      'bindAttribLocation': 3, 'bufferData': 3, 'bufferSubData': 3, 'drawArrays': 3, 'getFramebufferAttachmentParameter': 3, 'stencilFunc': 3, 'stencilOp': 3, 'texParameterf': 3, 'texParameteri': 3, 'uniform2f': 3, 'uniform2i': 3, 'uniformMatrix2fv': 3, 'uniformMatrix3fv': 3, 'uniformMatrix4fv': 3, 'vertexAttrib2f': 3, 'getBufferSubData': 3, 'getInternalformatParameter': 3, 'uniform2ui': 3, 'uniformMatrix2x3fv': 3, 'uniformMatrix3x2fv': 3, 'uniformMatrix2x4fv': 3, 'uniformMatrix4x2fv': 3, 'uniformMatrix3x4fv': 3, 'uniformMatrix4x3fv': 3, 'clearBufferiv': 3, 'clearBufferuiv': 3, 'clearBufferfv': 3, 'samplerParameteri': 3, 'samplerParameterf': 3, 'clientWaitSync': 3, 'waitSync': 3, 'transformFeedbackVaryings': 3, 'bindBufferBase': 3, 'getActiveUniforms': 3, 'getActiveUniformBlockParameter': 3, 'uniformBlockBinding': 3,-      'blendColor': 4, 'blendFuncSeparate': 4, 'clearColor': 4, 'colorMask': 4, 'drawElements': 4, 'framebufferRenderbuffer': 4, 'renderbufferStorage': 4, 'scissor': 4, 'stencilFuncSeparate': 4, 'stencilOpSeparate': 4, 'uniform3f': 4, 'uniform3i': 4, 'vertexAttrib3f': 4, 'viewport': 4, 'drawArraysInstanced': 4, 'uniform3ui': 4, 'clearBufferfi': 4,-      'framebufferTexture2D': 5, 'uniform4f': 5, 'uniform4i': 5, 'vertexAttrib4f': 5, 'drawElementsInstanced': 5, 'copyBufferSubData': 5, 'framebufferTextureLayer': 5, 'renderbufferStorageMultisample': 5, 'texStorage2D': 5, 'uniform4ui': 5, 'vertexAttribI4i': 5, 'vertexAttribI4ui': 5, 'vertexAttribIPointer': 5, 'bindBufferRange': 5,-      'texImage2D': 6, 'vertexAttribPointer': 6, 'invalidateSubFramebuffer': 6, 'texStorage3D': 6, 'drawRangeElements': 6,-      'compressedTexImage2D': 7, 'readPixels': 7, 'texSubImage2D': 7,-      'compressedTexSubImage2D': 8, 'copyTexImage2D': 8, 'copyTexSubImage2D': 8, 'compressedTexImage3D': 8,-      'copyTexSubImage3D': 9,-      'blitFramebuffer': 10, 'texImage3D': 10, 'compressedTexSubImage3D': 10,-      'texSubImage3D': 11 },-     hookWebGLFunction: function(f, glCtx) {       var realf = 'real_' + f;       glCtx[realf] = glCtx[f];-      var numArgs = GL.webGLFunctionLengths[f]; // On Firefox & Chrome, could do "glCtx[realf].length", but that doesn't work on Edge, which always reports 0.+      var numArgs = glCtx[realf].length;

Yes, totally standard! Even in older VMs: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/length

kripken

comment created time in 5 hours

PullRequestReviewEvent

Pull request review commentemscripten-core/emscripten

Simplify handling of exported native globals (namedGlobals)

 EMSCRIPTEN_KEEPALIVE int g_foo = 4;  EM_JS(int*, get_foo_from_js, (void), {-  assert(Module['_g_foo'] !== undefined, "g_foo not exported to JS");-  return Module['_g_foo'];+  assert(_g_foo !== undefined, "g_foo not exported to JS");

maybe assert > 0? that would also check it's not 0.

sbc100

comment created time in 7 hours

Pull request review commentemscripten-core/emscripten

Simplify handling of exported native globals (namedGlobals)

 def create_fp_accessors(metadata):   def create_named_globals(metadata):-  if not shared.Settings.RELOCATABLE:-    named_globals = []-    for k, v in metadata['namedGlobals'].items():+  named_globals = []+  for k, v in metadata['namedGlobals'].items():+    v = int(v)+    if shared.Settings.RELOCATABLE:+      v += shared.Settings.GLOBAL_BASE+    elif k == '__data_end':       # We keep __data_end alive internally so that wasm-emscripten-finalize knows where the       # static data region ends.  Don't export this to JS like other user-exported global       # address.-      if k not in ['__data_end']:-        named_globals.append("Module['_%s'] = %s;" % (k, v))-    return '\n'.join(named_globals)--  elements = ',\n  '.join('"' + k + '": ' + str(v) for k, v in metadata['namedGlobals'].items())-  named_globals = '''-var NAMED_GLOBALS = {-  %s-};-for (var named in NAMED_GLOBALS) {-  Module['_' + named] = %s + NAMED_GLOBALS[named];-}-Module['NAMED_GLOBALS'] = NAMED_GLOBALS;-''' % (elements, shared.Settings.GLOBAL_BASE)--  # wasm side modules are pure wasm, and cannot create their g$..() methods, so we help them out-  # TODO: this works if we are the main module, but if the supplying module is later, it won't, so-  #       we'll need another solution for that. one option is to scan the module imports, if/when-  #       wasm supports that, then the loader can do this.-  named_globals += '''-for (var named in NAMED_GLOBALS) {-  (function(named) {-    var addr = Module['_' + named];-    Module['g$_' + named] = function() { return addr };-  })(named);+      continue+    mangled = asmjs_mangle(k)+    if shared.Settings.MINIMAL_RUNTIME:+      named_globals.append("var %s = %s;" % (mangled, v))+    else:+      named_globals.append("var %s = Module['%s'] = %s;" % (mangled, mangled, v))

do we need the export on Module here? I think only for relocatable since the dynamic linker looks there?

(otherwise, I'd guess we should export on Module only stuff the user asked to export)

sbc100

comment created time in 7 hours

Pull request review commentemscripten-core/emscripten

Simplify handling of exported native globals (namedGlobals)

 var TARGET_NOT_SUPPORTED = 0x7FFFFFFF; // Wasm backend does not apply C name mangling (== prefix with an underscore) to // the following functions. (it also does not mangle any function that starts with // string "dynCall_")-var WASM_FUNCTIONS_THAT_ARE_NOT_NAME_MANGLED = ['setTempRet0', 'getTempRet0', 'stackAlloc', 'stackSave', 'stackRestore', '__growWasmMemory', '__heap_base', '__data_end'];+var WASM_FUNCTIONS_THAT_ARE_NOT_NAME_MANGLED = ['setTempRet0', 'getTempRet0', 'stackAlloc', 'stackSave', 'stackRestore', '__growWasmMemory', '__data_end'];

do we need __data_end in there?

sbc100

comment created time in 7 hours

PullRequestReviewEvent
PullRequestReviewEvent

PR opened emscripten-core/emscripten

GL tracing: read .length so we always have the right number of arguments.

Previously we had a hardcoded list that was written manually, which was needed for older browsers a while ago.

fixes #12353

+9 -16

0 comment

2 changed files

pr created time in 7 hours

push eventemscripten-core/emscripten

Benjamin Lee

commit sha 7069998c89a258719434f88ed77664e389bf9a4d

[docs] Fix markdown bold text typo (#12284)

view details

Sam Clegg

commit sha 2414b0d5fd334c02cf411f8b3d36c90af9d35f22

Remove use of `-Wno-almost-asm` (#12321)

view details

Alon Zakai

commit sha 001417595fcc5fb4825db8abf84fd0196255f2db

Fix a rare pthreads main thread deadlock that worsened in 2.0.2 (#12318) The deadlock was introduced in #12055 which was released in 2.0.2. However, the issue is deeper as the deadlock was just made more frequent by that. Background: Our pthreads implementation has some extra complexity because of how the main thread works on the web, specifically, we can't block there. So we can't do Atomics.wait there. Instead, we do a busy-wait in effect, and to make that as least bad as possible, we special case the main thread. There is a memory address, the "main thread futex address", which indicates the futex the main thread is waiting on, or 0 if none. When a thread runs futex_wake, it first checks if the main thread is waiting on that futex by checking that address, and if it is, we notify it first before any workers. In effect this gives the main thread priority. And by using that address, the main thread can busy-wait on it, just polling to see when a pthread sets it to 0, which indicates the wait can stop. This broke in #12055 because it erroneously ended up setting the main thread futex address only on the main thread. We did not get that address to workers. Instead, they got a JS undefined. So they would not wake up the main thread. It is actually a lot more complicated than that, because futex_wait can recurse: while it does the busy-wait loop, it will run the event loop, so it does not starve pthreads and get deadlocks - that is, it checks if there are incoming proxied calls, and it runs them. To run the event loop we must take a mutex. With the right timing we can hit the slow paths in both the original mutex (leading to a call to futex_wait instead of a quick atomic operation) and in the proxying mutex, and then we get this recursion. This was not handled by the old code correctly, in two ways. First, it did not clear the main thread futex address when futex_wait exits due to a timeout. So it looked like we were still waiting. A later futex_wake on that futex would unset the main thread futex address, counting that as one of the things it wakes up - but nothing was woken up there, so it ended up not waking anyone up (if it was told to just wake 1 person). Second, futex_wake did not check if it was on the main thread. The main thread should never wake itself up, but it did, making it more confusing (I'm not sure if this caused deadlocks by itself, though). A possible third issue is that when recursing in that way we could have the main thread in effect waiting on two futexes, A and then B. If a worker wants to wake up A while in the recursed call that set B, we don't see A in the main thread futex address - there is just one such address, and B has trampled it. The old code would actually just stop waiting in this case, since it looped while the address is the address we set, which means that after it called the nested wait, which wrote B, when we return to the first loop we'd see 0 (if the wait for B ended cleanly) or B (if we timed out and due the bug mentioned earlier we left B as the main thread futex address erroneously). And both are not A so we'd stop. That wasn't correct, though - it's possible we should still be waiting for A. To fix all this, this PR does two things: Allocate the main thread futex address in C, so that it is accessible in workers properly. Change how futex_wait works: it sets the main thread futex address and unsets it before exiting. It also unsets it before doing a nested call, so that they cannot interfere with each other. This also adds a lot of assertions in that code, which would have caught the previous bug, and I also verified happen on our test suite, so we have decent coverage. The one tricky thing here is handling the case in the paragraph from earlier with futexes A and B that we wait for in a nested manner. When nested, we wait until B is done, then return to the loop for A. How can we tell if A is done or not? The pthread waking it up may have already had its chance to wake it. The solution taken here is to read the futex's memory value, exactly like when starting in futex_wait. That is, futex_wait checks if an address has a value, and only if it does then it waits. I believe it is valid to check it later as well, since the result is the same as if the main thread were busy with other stuff, then checked the value later, after the other thread did some work. See the comment in the source for more details. This fixes a test that was wrong in how it handled a race condition, and adds a disabled test that was very useful for manual debugging here. That test hammers on all the proxying and locking mechanisms at once, basically. It's not a small little test, but I couldn't find a way to simplify it, and it's just for manual debugging.

view details

Sam Clegg

commit sha eb5a38e77f8501eb1bf695773defa5f4dee8676a

Update to latest xcode version (#12332) The xcode version is only really used when we want to do native clang build, and we recent ran into issues of compatiblity between our clang-12 binary and linker that is part of xcode 9.0.0. We were seeing clang pass `-platform_version` to the linker which is not a supported linker flag in xcode 9.0.0. I'm not sure exactly how this ever worked to why it broke in the last couple of days. Fixes: #12331

view details

Sam Clegg

commit sha 27a67869b2a9cd1c03eb5342d3ad950fabaceea7

Add tests for LIBRARY_DEBUG and SYSCALL_DEBUG (#12324) This uncovered a bug in SYSCALL_DEBUG in the absence of SYSCALLS_REQUIRE_FILESYSTEM.

view details

Sam Clegg

commit sha 101bac92c907cb8781b944c0c7faba73cfe3c625

Remove use of MEM_INIT_METHOD == 2 (#12325) These is no way to set MEM_INIT_METHOD to 2 these days. It cannot be used on the comment line (we error out if it is), and the only place it gets set in the source code we set it to 1.

view details

ShrekShao

commit sha 13eddf9aad21c5649ca7a7c1973bdea5c3ce1257

Add WEBGL_multi_draw_instanced_base_vertex_base_instance bindings (#12282) Add WEBGL_multi_draw_instanced_base_vertex_base_instance function bindings to emscripten. Add a test to verify the new functions hook up properly. Also fix a small bug in webgl2_simple_enable_extensions.c mentioned in #12280 (Thanks @kainino0x for catching the issue)

view details

Alon Zakai

commit sha 574b041f6ddb5b4db31b90db690ca3ac7165d334

Remove unnecessary testing in browser.test_pthread_gcc_atomic_fetch_and_op (#12333) We tested heavily because of the old regex stuff in fastcomp pthreads. Still seems useful to ensure one pthreads tests has all opt levels, but remove excessive debug levels. This makes the test 2x faster.

view details

Alon Zakai

commit sha 270f795c0492d681b55de89f9888cf577be9d4fc

Disable tests to allow LLVM to roll in (#12337) An atomics change landed on LLVM that will require #12056

view details

Alon Zakai

commit sha 5027d8c883b91f491cd70b7b3e78b0a378087ab1

Rewrite minifyGlobals JS optimizer pass (#12329) This fixes a bug that only became apparent when wasm2js started to emit more interesting JS code, which confused the pass. Historically the pass was just used on asm.js globals, which are trivial, and it was reused for wasm2js, but as wasm2js output changed we ran into the issue. Specifically, the old code made some assumptions about fastcomp output like that the first item shouldn't be minified, and that we can ignore some things and not others; those hacks are now all removed. The new design is cleaner and more general, but still not 100% fully general, see the corner case it doesn't handle in the comment. It may be good to handle that to prevent future bugs, but it would add significant complexity here. Adding just an assert might be better, but that would still need the complexity to reason about scopes. Unintentionally, this cleaner design can also do better at minifying, improving wasm2js hello world's total size by over 10% (!) This removes the old fastcomp-style handling in minifyGlobals, with the testcase for that. The new pass just focuses on wasm2js's output format. Once this lands we can re-enable minification in binaryen.js CI, which is disabled atm.

view details

Alon Zakai

commit sha 95358a3c962b56b00cb66f04f993cb8b2f93f14c

Disable another test for llvm roll (#12339)

view details

Alon Zakai

commit sha e43a870168dbae54eb8b652f4b0e9d579266e780

Make longjmp/exceptions helpers thread-safe (#12056) This adds the thread-local annotation to those globals. Previously they were in JS, which is effectively thread-local, but then we moved them to C which meant they were stored in the same shared memory for all threads. A race could happen if threads (or longjmp) operations happened at just the right time, one writing to those globals and another reading. Also make compiler-rt now build with a multithreaded variation, as the implementation of those globals is in that library. Also add a testcase that runs exceptions on multiple threads. It's not a guaranteed way to notice a race, but it may help, and this is an area we didn't have coverage of. Fixes #12035 This has been a possible race condition for a very long time. I think it went unnoticed because exceptions and longjmp tend to be used for exceptional things, and not constantly being executed. And also until we get wasm exceptions support they are also slow, so people have been trying to avoid them as much as possible anyhow.

view details

Sam Clegg

commit sha c099075e4838ed05bc68fe99f6538941ba20b03d

Update add_dylink_section to work with wasm backend. (#11028) In this case its jobs is to add the dso dependencies since that other fields are already present.

view details

Sam Clegg

commit sha d021a984b8909b78b1cdd653c0fb302383a31306

tests: Removal of @no_wasm_backend, part 1 (#12338) This change removes the use of this decorator from the other and sanity test suites. Some tests simply worked, some make no sense with wasm backend and a couple are tests we would like revive once day (related to ctor evaluation and ctor elimiation). There was one test for which I implemented the feature which was to ingnore multiple copies of the same .so file on the link line. This improves the fake shared library support a little and was a feature of fastcomp. See: #12335

view details

Sam Clegg

commit sha b1e5be9cbb01dbf018580dd8e3ba42dd07f1a329

Update google-closure-compiler (#12345) This change was generated by running: `npm install google-closure-compiler@latest` I the removed the `^` which `npm install` put that beginning of the version so that we are precise in the version we are using.

view details

Alon Zakai

commit sha e00d6a04bb0a7b5e3c240fc560d4b66703bffab0

2.0.5

view details

Sam Clegg

commit sha 1130cd5b78f5827bcf75e9cf39f445bc7f4c0338

Remove old reference to _llvm_global_ctors. NFC. (#12358) I assume this was some kind of fastcomp thing. I can't find any reference to it anymore.

view details

Sam Clegg

commit sha 49bc8c54056c1b45688fc54ea80ed59e2ba18b21

parseTools.js: Remove more dead code. NFC. (#12357)

view details

Sam Clegg

commit sha 81a65b1270c7c3017813ea50d9829843f0aa9df9

Ensure proxyfs is correctly included when -lprozyfs.js is specified (#12352) Also, remove EXPORT_ALL and MAIN_MODULE from test_proxyfs in favor of being more precise in what we want to export. Fixes: #12351

view details

Ingvar Stepanyan

commit sha 1e455ef327f072a3d693e35fac964d2ce878511a

Bump ES version to 2020 (#12343) Fixes #11303.

view details

push time in 8 hours

issue commentemscripten-core/emscripten

Heap growth notifications

I agree this can be annoying, yeah, Web APIs make it easy to miss this and get bad results.

One way to do this right now is to monkeypatch wasmMemory.grow, which is what we call from JS to grow, to run some code in the middle. Another way is to reimplement $emscripten_realloc_buffer in a JS library, which would override the default implementation from library.js (you'd need to do the same things the current code does, but it's just a few lines).

Optimally the wasm JS API would provide a callback, but there isn't agreement on that, https://github.com/WebAssembly/design/issues/1296 :cry:

kg

comment created time in 8 hours

pull request commentemscripten-core/emsdk

Set user environment variables permanently by using `--permanent` + deprecate `--global`

I don't have a preference between --persistent vs --permanent.

I think if the code looks good to you @sbc100 , let's land it!

aminya

comment created time in 8 hours

PullRequestReviewEvent

issue commentemscripten-core/emscripten

Collision of minified names

Binaryen minified names shouldn't reach the global namespace, I don't think? Only the exports should, but those aren't minified? Sorry if I'm missing something obvious. Even without a reproducing testcase, more details could help understand what you mean @Mintyboi

Mintyboi

comment created time in 8 hours

issue commentemscripten-core/emscripten

add uploader demo to tests

I don't think anyone's done work on this - a PR with a docs addition would be nice!

netpipe

comment created time in 8 hours

create barnchemscripten-core/emscripten

branch : trace

created branch time in 8 hours

PullRequestReviewEvent
PullRequestReviewEvent

issue commentwasmerio/wasmer

Error in running wasm (siglongjmp)

@danchitnis That demo implemented longjmp using asyncify - a way to work around current wasm limitations. It ran on any VM.

Otherwise, siglongjmp is the same as longjmp. If wasmer supports the latter, doing the same for siglongjmp should work.

danchitnis

comment created time in 9 hours

PullRequestReviewEvent

push eventWebAssembly/binaryen

Alon Zakai

commit sha 2a869194c5fb7f54b3811043bfcf723e3d53c1df

Restore minification in emscripten builds (#3173) The emscripten bug has been fixed in emscripten-core/emscripten#12329

view details

push time in a day

delete branch WebAssembly/binaryen

delete branch : un

delete time in a day

PR merged WebAssembly/binaryen

Restore minification in emscripten builds

The emscripten bug has been fixed in https://github.com/emscripten-core/emscripten/pull/12329

+4 -5

1 comment

1 changed file

kripken

pr closed time in a day

pull request commentWebAssembly/binaryen

Restore minification in emscripten builds

Yes, it's just a re-enabling.

kripken

comment created time in a day

push eventkripken/emscripten-site

Alon Zakai

commit sha e4e7cb7a310ad509ef63f800e311ea356e3e89d3

update

view details

push time in a day

created tagemscripten-core/emsdk

tag2.0.5

Emscripten SDK

created time in a day

created tagemscripten-core/emscripten

tag2.0.5

Emscripten: An LLVM-to-WebAssembly Compiler

created time in a day

push eventemscripten-core/emscripten

Alon Zakai

commit sha e00d6a04bb0a7b5e3c240fc560d4b66703bffab0

2.0.5

view details

push time in a day

push eventemscripten-core/emsdk

Alon Zakai

commit sha 7e841b59fce9264b1c93351252defa3797b33b64

2.0.5 (#625)

view details

push time in a day

delete branch emscripten-core/emsdk

delete branch : update

delete time in a day

PR merged emscripten-core/emsdk

2.0.5
+5 -4

0 comment

2 changed files

kripken

pr closed time in a day

PR opened emscripten-core/emsdk

Reviewers
2.0.5
+5 -4

0 comment

2 changed files

pr created time in a day

create barnchemscripten-core/emsdk

branch : update

created branch time in a day

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentemscripten-core/emscripten

Remove builtin primitive concept from jsifier

 assert(Math.fround, 'This browser does not support Math.fround(), build with LEG assert(Math.clz32, 'This browser does not support Math.clz32(), build with LEGACY_VM_SUPPORT or POLYFILL_OLD_MATH_FUNCTIONS to add in a polyfill'); assert(Math.trunc, 'This browser does not support Math.trunc(), build with LEGACY_VM_SUPPORT or POLYFILL_OLD_MATH_FUNCTIONS to add in a polyfill'); #endif--var Math_abs = Math.abs;-var Math_cos = Math.cos;-var Math_sin = Math.sin;-var Math_tan = Math.tan;-var Math_acos = Math.acos;-var Math_asin = Math.asin;-var Math_atan = Math.atan;-var Math_atan2 = Math.atan2;-var Math_exp = Math.exp;-var Math_log = Math.log;-var Math_sqrt = Math.sqrt;-var Math_ceil = Math.ceil;-var Math_floor = Math.floor;-var Math_pow = Math.pow;-var Math_imul = Math.imul;-var Math_fround = Math.fround;-var Math_round = Math.round;-var Math_min = Math.min;-var Math_max = Math.max;-var Math_clz32 = Math.clz32;-var Math_trunc = Math.trunc;

this lgtm if there is no code size downside with closure (if tests pass, I guess not).

sbc100

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

push eventWebAssembly/binaryen

Alon Zakai

commit sha c721f85e79f97936f4804afe51dcd2859ad13afd

Fix low_pc updating when the expression is right at the start (#3175) In that case LLVM emits the address of the declarations area (where locals are declared) of the function, which is even earlier than the instructions actual first byte. I'm not sure why it does this, but it's easy to handle.

view details

push time in a day

delete branch WebAssembly/binaryen

delete branch : instart

delete time in a day

PR merged WebAssembly/binaryen

Fix low_pc updating when the expression is right at the start

In that case LLVM emits the address of the declarations area (where locals are declared) of the function, which is even earlier than the instructions actual first byte. I'm not sure why it does this, but it's easy to handle.

+507 -1

0 comment

4 changed files

kripken

pr closed time in a day

push eventWebAssembly/binaryen

Alon Zakai

commit sha 893e1cfb22d205eae2e02fdf381178f557f4ee09

rename testcase so windows knows to skip it

view details

push time in a day

PR opened WebAssembly/binaryen

Fix low_pc updating when the expression is right at the start

In that case LLVM emits the address of the declarations area (where locals are declared) of the function, which is even earlier than the instructions actual first byte. I'm not sure why it does this, but it's easy to handle.

+507 -1

0 comment

4 changed files

pr created time in a day

push eventWebAssembly/binaryen

Alon Zakai

commit sha 8672c3dfadfbaf12f94acf326a69c31612024d91

smaller

view details

push time in a day

push eventWebAssembly/binaryen

Alon Zakai

commit sha 3575166a25129257f6547ad4d280169385a25f0b

fix

view details

push time in a day

create barnchWebAssembly/binaryen

branch : instart

created branch time in a day

push eventWebAssembly/binaryen

Alon Zakai

commit sha b1a11a6e84e73600b0d743a490847ba5a72c31dc

more

view details

push time in 2 days

push eventWebAssembly/binaryen

Alon Zakai

commit sha 201c6cc4c2ee04d75815e75dd6704853186d56b0

more

view details

push time in 2 days

push eventWebAssembly/binaryen

Alon Zakai

commit sha d9293e3feeed002ca7b0e4651eec9ba9b1d75c73

more

view details

push time in 2 days

create barnchWebAssembly/binaryen

branch : jsc

created branch time in 2 days

pull request commentemscripten-core/emscripten

Mt deadlock issue

I think the main issue with the current implementation is that a mutex is expected to block execution. Due to the nature of the browser implementation this is not completely possible as things like memory allocation need to be delegated to the main thread.

That's not accurate for memory allocation. malloc and free do take a mutex, but no proxying happens, and the operations they do while holding the mutex do not depend on another thread, so they are guaranteed to run to completion and not deadlock, AFAIK.

Other things do need to be delegated to the main thread, like I/O, so if the main thread blocks on a worker which is doing I/O that can be dangerous, you are definitely right there.

#10155 has two examples of known current deadlocks. Does this PR fix them? If so that could help understand what's going on here.

(If not, then note that #12318 and #12240 have landed, both of which may be relevant, so you can test them on a tip of tree build, emsdk install tot.)

AlexanderJ

comment created time in 4 days

Pull request review commentemscripten-core/emscripten

tests: Removal of @no_wasm_backend, part 1

 def test_fs_after_main(self):       self.run_process([EMCC, path_from_root('tests', 'fs_after_main.cpp')])       self.assertContained('Test passed.', self.run_js('a.out.js')) -  @no_wasm_backend('tests fastcomp compiler flags')   def test_os_oz(self):     for arg, expect in [         ('-O1', '-O1'),-        ('-O2', '-O3'),+        ('-O2', '-O2'),

can replace the pairs with single values as they are now always identical

sbc100

comment created time in 4 days

Pull request review commentemscripten-core/emscripten

tests: Removal of @no_wasm_backend, part 1

 def check(input_file):         return [f for f in inputs if check(f[1])]       return inputs +    def filter_out_duplicate_dynamic_libs(inputs):+      # Filter out duplicat eshared libraries.+      # See test_core.py:test_redundant_link+      seen = set(inputs)

shouldn't this be:

      seen = set()

?

sbc100

comment created time in 4 days

Pull request review commentemscripten-core/emscripten

tests: Removal of @no_wasm_backend, part 1

 def check(input_file):         return [f for f in inputs if check(f[1])]       return inputs +    def filter_out_duplicate_dynamic_libs(inputs):+      # Filter out duplicat eshared libraries.
      # Filter out duplicate shared libraries.
sbc100

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventemscripten-core/emscripten

Alon Zakai

commit sha e43a870168dbae54eb8b652f4b0e9d579266e780

Make longjmp/exceptions helpers thread-safe (#12056) This adds the thread-local annotation to those globals. Previously they were in JS, which is effectively thread-local, but then we moved them to C which meant they were stored in the same shared memory for all threads. A race could happen if threads (or longjmp) operations happened at just the right time, one writing to those globals and another reading. Also make compiler-rt now build with a multithreaded variation, as the implementation of those globals is in that library. Also add a testcase that runs exceptions on multiple threads. It's not a guaranteed way to notice a race, but it may help, and this is an area we didn't have coverage of. Fixes #12035 This has been a possible race condition for a very long time. I think it went unnoticed because exceptions and longjmp tend to be used for exceptional things, and not constantly being executed. And also until we get wasm exceptions support they are also slow, so people have been trying to avoid them as much as possible anyhow.

view details

push time in 4 days

delete branch emscripten-core/emscripten

delete branch : exc

delete time in 4 days

PR merged emscripten-core/emscripten

Make longjmp/exceptions helpers thread-safe

This adds the thread-local annotation to those globals. Previously they were in JS, which is effectively thread-local, but then we moved them to C which meant they were stored in the same shared memory for all threads. A race could happen if threads (or longjmp) operations happened at just the right time, one writing to those globals and another reading.

Also make compiler-rt now build with a multithreaded variation, as the implementation of those globals is in that library.

Also add a testcase that runs exceptions on multiple threads. It's not a guaranteed way to notice a race, but it may help, and this is an area we didn't have coverage of.

Fixes https://github.com/emscripten-core/emscripten/issues/12035

This has been a possible race condition for a very long time. I think it went unnoticed because exceptions and longjmp tend to be used for exceptional things, and not constantly being executed. And also until we get wasm exceptions support they are also slow, so people have been trying to avoid them as much as possible anyhow.

+87 -17

26 comments

7 changed files

kripken

pr closed time in 4 days

issue closedemscripten-core/emscripten

Exception Handling - exception on the wrong thread when using pthreads

We have a large project which now runs pretty well except for the one module that uses C++ exceptions extensively. We generally have 3 pthreads running and what we see is that the expection on pthread A is thrown and then caught by any of the 3 pthreads (A, B or C) when it should always be A. Having pthread B or C don't have catches for that exception type, so those fall out (worker.js onmessage() captured an uncaught exception: RuntimeError: unreachable executed) and pthread A which needed the exception goes down error paths and often gets an index out of bounds exception trying to run code it shouldn't be. If I remove the other pthreads and only have the one, main pthread (losing the functionality of those other threads for the sake of this investigation - not a viable solution), we don't seem to have this issue but we are not convinced that that conclusion is not just circumstantial.

We have seen these issues with EMSDK 1.39.17, 1.39.20 and 2.0.0. We are building with -O1 which then requires -s DISABLE_EXCEPTION_CATCHING=0 per https://emscripten.org/docs/optimizing/Optimizing-Code.html#optimizing-code-exception-catching, but we have seen the issue with -O0 too.

Per ajeejin's May 28th comment from https://github.com/emscripten-core/emscripten/issues/11233, we tried to build with -s DISABLE_EXCEPTION_CATCHING=0 removed and -fwasm-exceptions. 2 modules got clang++ errors saying to submit a but to bugs.llvm.org including some files, but our company legal hasn't cleared us to do that because the files are basically the source code. I did try those 2 modules without -fwasm-exceptions and all the other modules with -fwasm-exceptions, but that didn't run: wasm streaming compile failed: CompileError: wasm validation error: at offset 146711: unknown section before code section falling back to ArrayBuffer instantiation failed to asynchronously prepare wasm: CompileError: wasm validation error: at offset 146711: expected code section CompileError: wasm validation error: at offset 146711: expected code section These exceptions are thrown and should be caught in the C++ code (not javascript), so https://emscripten.org/docs/porting/Debugging.html#handling-c-exceptions-from-javascript should not apply.

Are there additional settings that we need to have these exceptions be thrown and caught by the correct (same) thread (I have read through the Emscripten doc and tried all sorts of combinations of -S and other settings - all to no avail)? Is there anything to do until the new exception handling (-fwasm-exceptions) is done and ready? Is this a known issue for the existing exception handling that will be fixed? I don't have a test case outside of our real code that I can share - is it worth my time to work on a test case that I can share or is this already known and will be addressed (I don't want to waste time on the test case if it isn't needed but if this can/should be fixed on the existing exception handling infrastructure, I'm certainly will to go spend that time)?

closed time in 4 days

rsielken

issue commentemscripten-core/emscripten

Exception Handling - exception on the wrong thread when using pthreads

I verified this is fixed by #12056 which will land shortly.

Thanks again for the testcase @rsielken , it's been very helpful!

rsielken

comment created time in 4 days

push eventemscripten-core/emscripten

Alon Zakai

commit sha 84ab45b451b690276e7fdd63ce95aa465a58f908

remove unneeded change after the llvm change

view details

push time in 4 days

issue commentemscripten-core/emscripten

A question about how EMCC implements WASI

We could add an ONLY_WASI option to emscripten, which would severely limit the number of programs you could compile, but perhaps it would be useful?

I think it would be useful together with an implementation to use WASI syscalls as much as possible.

See previous discussion in https://github.com/emscripten-core/emscripten/issues/12073 . @mejedi perhaps you'll have time for a PR as discussed there?

wustwn

comment created time in 4 days

pull request commentemscripten-core/emscripten

Make longjmp/exceptions helpers thread-safe

Passes locally for me with that patch. Uploaded simplified version here that can be run once that has rolled in.

kripken

comment created time in 4 days

push eventemscripten-core/emscripten

Alon Zakai

commit sha 36c0ee07d8656f93c75bd53aaa1e0aec7630134d

-mt

view details

Alon Zakai

commit sha 05257b870037b0edb9c34bfc41f6d578478f2dec

Revert "-mt" This reverts commit 36c0ee07d8656f93c75bd53aaa1e0aec7630134d.

view details

Alon Zakai

commit sha 5657df5eb323e1c2b831a6a83ea5998ee57359e5

Revert "embind and asan_js libraries now also need to be built with -mt" This reverts commit d42e14854cd69d21f118e31927772726fc2fd56f.

view details

Alon Zakai

commit sha b312b573cadfa0a489d4e0c19fd413e4d8e43c5d

Revert "Also build libc_rt_wasm with -mt when needed" This reverts commit 7955ce2f3cad124fed77fb28f0fe7c0e2b3d581d.

view details

Alon Zakai

commit sha 44b8dda3eb479e62c2937fcd5de24044b9b18a08

fix comment

view details

Alon Zakai

commit sha 704a676082caeeb08bd8440d7e1e631fecd0432c

cleaner [ci skip]

view details

push time in 4 days

pull request commentemscripten-core/emscripten

Make longjmp/exceptions helpers thread-safe

It may be good to land this as-is (with the comment cleanup @sbc100 mentioned) as it now passes tests while enabling the ones that were disabled, so it is strictly better than what is in trunk atm. Then after the LLVM update we can adjust.

However if we think the LLVM update may end up not rolling in by us re-enabling tests here, we should probably just wait, to avoid any annoying back-and-forth.

kripken

comment created time in 4 days

Pull request review commentemscripten-core/emscripten

Make longjmp/exceptions helpers thread-safe

 class libwebgpu_cpp(MTLibrary):   src_files = ['webgpu_cpp.cpp']  -class libembind(Library):

Building bind.o with an -mt variant fixes it, of course.

What's not clear to me is why this worked before, and what @tlively 's change in LLVM makes different so that it doesn't work now...

kripken

comment created time in 4 days

PullRequestReviewEvent

Pull request review commentemscripten-core/emscripten

Make longjmp/exceptions helpers thread-safe

 class libwebgpu_cpp(MTLibrary):   src_files = ['webgpu_cpp.cpp']  -class libembind(Library):

Specifically

wasm-ld: error: --shared-memory is disallowed by bind.o because it was not compiled with 'atomics' or 'bulk-memory' features.
kripken

comment created time in 4 days

PullRequestReviewEvent

Pull request review commentemscripten-core/emscripten

Make longjmp/exceptions helpers thread-safe

  * Emscripten is available under two separate licenses, the MIT license and the  * University of Illinois/NCSA Open Source License.  Both these licenses can be  * found in the LICENSE file.- *- * Support functions for emscripten setjmp/longjmp and exception handling- * support.- * See: https://llvm.org/doxygen/WebAssemblyLowerEmscriptenEHSjLj_8cpp.html

Thanks, I removed too much comment here, will restore.

kripken

comment created time in 4 days

PullRequestReviewEvent

Pull request review commentemscripten-core/emscripten

Make longjmp/exceptions helpers thread-safe

 class libwebgpu_cpp(MTLibrary):   src_files = ['webgpu_cpp.cpp']  -class libembind(Library):

The usual error on features not matching: can't link in this .o because it disallows atomics.

kripken

comment created time in 4 days

PullRequestReviewEvent

pull request commentemscripten-core/emscripten

Make longjmp/exceptions helpers thread-safe

asan_js does not use exceptions or longjmp. Literally the only difference in the .o files (between the normal and -mt versions of it) is the features section. So I'm not sure why the LLVM change made us need to build it with an -mt variation while before we didn't...

@tlively I'm very confused here, please help...

kripken

comment created time in 5 days

pull request commentemscripten-core/emscripten

Make longjmp/exceptions helpers thread-safe

A bunch more libraries must now be built with -mt variations, asan_js and embind. I am not actually sure why these and not others, so this worries me - will users hit more library combinations we don't test?

It seems like when the user builds with pthreads, we now need all libraries to be built with atomics. So it's not just some libraries we annotate with -mt, but they all must be. So like relocatable, we may as well have another cache dir, really.

Or is this just libraries that use setjmp or exceptions, and so they have __THREW__ which is now atomic?

kripken

comment created time in 5 days

push eventemscripten-core/emscripten

Alon Zakai

commit sha d42e14854cd69d21f118e31927772726fc2fd56f

embind and asan_js libraries now also need to be built with -mt

view details

push time in 5 days

PullRequestReviewEvent

push eventWebAssembly/binaryen

Daniel Wirtz

commit sha 46d2cbab48ebbc8c9aab3f285cc42b2544bb526a

Fix missing feature validations (#3171) Instructions `ref.null`, `ref.is_null`, `ref.func`, `try`, `throw`, `rethrow` and `br_on_exn` were previously missing explicit feature checks, and this change adds them. Note that some of these already didn't validate before for other reasons, like requiring the use of a type checked otherwise, but `ref.null` and `try` validated even in context of FeatureSet::MVP, so better to be sure.

view details

Alon Zakai

commit sha f03480b95ba714bc0ba5c64d7d6089f107aee0b9

Merge remote-tracking branch 'origin/master' into un

view details

push time in 5 days

push eventemscripten-core/emscripten

Alon Zakai

commit sha c76b122b9d6020a0c35bee684799dc62545f8f72

comment

view details

push time in 5 days

PR opened WebAssembly/binaryen

Restore minification in emscripten builds

The emscripten bug has been fixed in https://github.com/emscripten-core/emscripten/pull/12329

+4 -5

0 comment

1 changed file

pr created time in 5 days

push eventemscripten-core/emscripten

Alon Zakai

commit sha 95358a3c962b56b00cb66f04f993cb8b2f93f14c

Disable another test for llvm roll (#12339)

view details

Alon Zakai

commit sha 586767ea64e32f12bef736c3e0dff3b612ed1eb7

Merge remote-tracking branch 'origin/master' into exc

view details

Alon Zakai

commit sha e55647a396a1578cc16ef4580ccb03adc4accd73

revert the extra disabled test too [ci skip]

view details

push time in 5 days

push eventemscripten-core/emscripten

Alon Zakai

commit sha 95358a3c962b56b00cb66f04f993cb8b2f93f14c

Disable another test for llvm roll (#12339)

view details

push time in 5 days

delete branch emscripten-core/emscripten

delete branch : roll

delete time in 5 days

PR merged emscripten-core/emscripten

Disable another test for llvm roll

Somehow I missed this one the first time :cry:

+1 -0

0 comment

1 changed file

kripken

pr closed time in 5 days

PR opened emscripten-core/emscripten

Disable another test for llvm roll

Somehow I missed this one the first time :cry:

+1 -0

0 comment

1 changed file

pr created time in 5 days

create barnchemscripten-core/emscripten

branch : roll

created branch time in 5 days

pull request commentemscripten-core/emscripten

Make longjmp/exceptions helpers thread-safe

This now includes undoing the test disabling in #12337. After LLVM rolls in this should pass. Locally it looks ok for me on the disabled tests.

Note that I had to fix up one test, test_warning_flags, and also I had to add libc_rt_wasm to also have a multithreaded variation.

kripken

comment created time in 5 days

push eventemscripten-core/emscripten

Sam Clegg

commit sha 27a67869b2a9cd1c03eb5342d3ad950fabaceea7

Add tests for LIBRARY_DEBUG and SYSCALL_DEBUG (#12324) This uncovered a bug in SYSCALL_DEBUG in the absence of SYSCALLS_REQUIRE_FILESYSTEM.

view details

Sam Clegg

commit sha 101bac92c907cb8781b944c0c7faba73cfe3c625

Remove use of MEM_INIT_METHOD == 2 (#12325) These is no way to set MEM_INIT_METHOD to 2 these days. It cannot be used on the comment line (we error out if it is), and the only place it gets set in the source code we set it to 1.

view details

ShrekShao

commit sha 13eddf9aad21c5649ca7a7c1973bdea5c3ce1257

Add WEBGL_multi_draw_instanced_base_vertex_base_instance bindings (#12282) Add WEBGL_multi_draw_instanced_base_vertex_base_instance function bindings to emscripten. Add a test to verify the new functions hook up properly. Also fix a small bug in webgl2_simple_enable_extensions.c mentioned in #12280 (Thanks @kainino0x for catching the issue)

view details

Alon Zakai

commit sha 574b041f6ddb5b4db31b90db690ca3ac7165d334

Remove unnecessary testing in browser.test_pthread_gcc_atomic_fetch_and_op (#12333) We tested heavily because of the old regex stuff in fastcomp pthreads. Still seems useful to ensure one pthreads tests has all opt levels, but remove excessive debug levels. This makes the test 2x faster.

view details

Alon Zakai

commit sha 270f795c0492d681b55de89f9888cf577be9d4fc

Disable tests to allow LLVM to roll in (#12337) An atomics change landed on LLVM that will require #12056

view details

Alon Zakai

commit sha 5027d8c883b91f491cd70b7b3e78b0a378087ab1

Rewrite minifyGlobals JS optimizer pass (#12329) This fixes a bug that only became apparent when wasm2js started to emit more interesting JS code, which confused the pass. Historically the pass was just used on asm.js globals, which are trivial, and it was reused for wasm2js, but as wasm2js output changed we ran into the issue. Specifically, the old code made some assumptions about fastcomp output like that the first item shouldn't be minified, and that we can ignore some things and not others; those hacks are now all removed. The new design is cleaner and more general, but still not 100% fully general, see the corner case it doesn't handle in the comment. It may be good to handle that to prevent future bugs, but it would add significant complexity here. Adding just an assert might be better, but that would still need the complexity to reason about scopes. Unintentionally, this cleaner design can also do better at minifying, improving wasm2js hello world's total size by over 10% (!) This removes the old fastcomp-style handling in minifyGlobals, with the testcase for that. The new pass just focuses on wasm2js's output format. Once this lands we can re-enable minification in binaryen.js CI, which is disabled atm.

view details

Alon Zakai

commit sha 7955ce2f3cad124fed77fb28f0fe7c0e2b3d581d

Also build libc_rt_wasm with -mt when needed

view details

Alon Zakai

commit sha 96cbf74a4c305a4a92a2c86c2c875b3e10de6d20

fix test

view details

Alon Zakai

commit sha af889b04dd18b82c82bb2d2d4c313818778b0b78

Merge remote-tracking branch 'origin/master' into exc

view details

Alon Zakai

commit sha 06296089394a107d974e5ee36b3f8e2c003a4f54

Revert "Disable tests to allow LLVM to roll in (#12337)" This reverts commit 270f795c0492d681b55de89f9888cf577be9d4fc.

view details

Alon Zakai

commit sha 9e6193eda4e0db9793bbce845871b1c4aa191e6b

[ci skip]

view details

push time in 5 days

create barnchWebAssembly/binaryen

branch : un

created branch time in 5 days

more