Re: wasm-ld: error: --shared-memory is disallowed by lto.tmp because it was not compiled with 'atomics' or 'bulk-memory' features.

['Thomas Lively' via emscripten-discuss]

> Do I even need the -pthread flag to use CPP threads, or is it only
necessary for some JS threads I am yet to undestand?

Yes you do.

> Refused to execute script from '
http://localhost:8000/blink_landmark_detector_sample.js' because its MIME
type ('text/plain') is not executable.

This is probably also a server configuration problem. The MIME type for JS
should be text/javascript.

On Fri, Jul 21, 2023 at 1:05 AM Shlomi Fish  wrote:

> hi,
>
> On Thu, 20 Jul 2023 00:47:07 -0700 (PDT)
> Ronny Nissengold  wrote:
>
> > Using malloc didn't work.
>
> did using cwrap() work? see:
>
>
> https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html
>
> > By setting the coop policy, using requestly, I now get new errors:
> > Refused to execute script from
> > 'http://localhost:8000/blink_landmark_detector_sample.js' because its
> MIME
> > type ('text/plain') is not executable.
> > At least now SharedArrayBuffer is recognised.
> > Looks like I am close but still no cigar.
> > Any ideas?
> > Thanks.
> >
> > ב-יום חמישי, 20 ביולי 2023 בשעה 09:55:27 UTC+3, Shlomi Fish כתב/ה:
> >
> > > hi Ronny!
> > >
> > > On Wed, 19 Jul 2023 02:45:53 -0700 (PDT)
> > > Ronny Nissengold  wrote:
> > >
> > > > Thank you all for your support.
> > > > I was able to successfully compile my project with pthread enabled.
> > > > Now I face a new problem, I used Module._malloc to pass an image
> from a
> > > > webcam into my cpp function
> > > > For that I used the following linker
> > > > flags: add_link_options(-sINITIAL_MEMORY=800MB -sTOTAL_STACK=80MB
> -O3 -s
> > > > -sEXPORTED_FUNCTIONS=['_malloc','_free'] -sASSERTIONS -pthread)
> > > >
> > > > Now I get the following error in my console:
> > > >
> > > > Uncaught ReferenceError: SharedArrayBuffer is not defined
> > > > at blink_landmark_detector_sample.js:1:
> > > >
> > > > (index):11 Uncaught TypeError: Module._malloc is not a function
> > > > at _arrayToHeap ((index):11:24)
> > > > at HTMLVideoElement.computeFrame ((index):40:22)
> > > >
> > > > Any idea what happened?
> > >
> > > try using 'Module.malloc' [without the underscore] or 'cwrap'.
> > >
> > > HTH
>
>
>
> --
>
> Shlomi Fish   https://www.shlomifish.org/
> https://www.shlomifish.org/humour/bits/New-versions-of-the-GPL/
>
> Yawn! Too TL;DR! Dude, do you even tweet?
> — https://twitter.com/shlomif/status/504931822757638144
>
> Please reply to list if it's a mailing list post - https://shlom.in/reply
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/20230721085722.232c69e3%40telaviv1.shlomifish.org
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EUEBxVf2FtsoiVhsL7C%3DKVoW%3DYsLZLwj9dN%3DVXNmdezeg%40mail.gmail.com.

Re: wasm-ld: error: --shared-memory is disallowed by lto.tmp because it was not compiled with 'atomics' or 'bulk-memory' features.

['Thomas Lively' via emscripten-discuss]

Do you perhaps not have your COOP and COEP headers set? Those are required
to make SharedArrayBuffer (and Wasm threads in general) available.
https://web.dev/coop-coep/

On Wed, Jul 19, 2023 at 5:56 AM Ronny Nissengold 
wrote:

> Just to make a few things clear:
> 1. I used to have a CPP thread which crashed whenever trying to create the
> thread. I removed it and then my WASM code worked perfectly.
> 2. (Not sure if relevant) What my code does is basically- Receive an image
> from Webcam, copy it to a JS arrayBuffer, call a callback to my CPP
> function, modify the image in cpp, return the image, and paint it on a
> canvas. With some cool AI in the process with OnnxRuntime and OpenCV
> compiled in ;)
> 3. I do want to use CPP threads, so to solve 1, I recompiled everything
> with -pthread, and then everything successfully recompiled.  Also some
> worker.js was created I am not sure what to do with...
> 4. After I thought I am finished, somehow the project forgot what
> SharedArrayBuffer is, which I guess causes all the other errors as well.
> ב-יום רביעי, 19 ביולי 2023 בשעה 12:45:53 UTC+3, ‪Ronny Nissengold‬‏ כתב/ה:
>
>> Thank you all for your support.
>> I was able to successfully compile my project with pthread enabled.
>> Now I face a new problem, I used Module._malloc to pass an  image from a
>> webcam into my cpp function
>> For that I used the following linker
>> flags: add_link_options(-sINITIAL_MEMORY=800MB -sTOTAL_STACK=80MB -O3 -s
>> -sEXPORTED_FUNCTIONS=['_malloc','_free'] -sASSERTIONS -pthread)
>>
>> Now I get the following error in my console:
>>
>> Uncaught ReferenceError: SharedArrayBuffer is not defined
>> at blink_landmark_detector_sample.js:1:
>>
>> (index):11 Uncaught TypeError: Module._malloc is not a function
>> at _arrayToHeap ((index):11:24)
>> at HTMLVideoElement.computeFrame ((index):40:22)
>>
>> Any idea what happened?
>> Thanks!
>> Ronny
>> ב-יום שלישי, 18 ביולי 2023 בשעה 16:06:32 UTC+3, tli...@google.com כתב/ה:
>>
>>> If you look at your CMake script, you should see that it adds -flto at
>>> some point. That’s the option you’ll want to remove. You may be able to
>>> remove it from your CMakeCache.txt file and recompile without running cmake
>>> again.
>>>
>>> On Tue, Jul 18, 2023 at 01:33 Ronny Nissengold 
>>> wrote:
>>>
 Thank you for your response. How do I turn off LTO?

 ב-יום שני, 17 ביולי 2023 בשעה 18:51:26 UTC+3, tli...@google.com כתב/ה:

> This error means that some code wasn't compiled with -pthread and
> therefore is not safe to execute in a multithreaded environment. Normally
> the error message tells you which object is the culprit, but it's less
> helpful here because you're using LTO. Does the problem persist if you 
> turn
> off LTO?
>
> On Mon, Jul 17, 2023 at 8:49 AM Ronny Nissengold 
> wrote:
>
>> Hi all!
>> I am trying to use multithreading in my project.
>> I got this error when passing -pthread both to compiler and linker.
>> I am using cmake.
>> Any idea how to overcome this?
>> Thanks!
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to emscripten-disc...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/acbc873e-078a-4082-8761-6c0322246170n%40googlegroups.com
>> 
>> .
>>
> --
 You received this message because you are subscribed to the Google
 Groups "emscripten-discuss" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to emscripten-disc...@googlegroups.com.

>>> To view this discussion on the web visit
 https://groups.google.com/d/msgid/emscripten-discuss/3c0a9c3c-9e56-41e4-9211-38afba0fc2c2n%40googlegroups.com
 
 .

>>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/a82fa172-4875-4b42-a1fb-ed7237ca6d9bn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an 

Re: wasm-ld: error: --shared-memory is disallowed by lto.tmp because it was not compiled with 'atomics' or 'bulk-memory' features.

['Thomas Lively' via emscripten-discuss]

If you look at your CMake script, you should see that it adds -flto at some
point. That’s the option you’ll want to remove. You may be able to remove
it from your CMakeCache.txt file and recompile without running cmake again.

On Tue, Jul 18, 2023 at 01:33 Ronny Nissengold  wrote:

> Thank you for your response. How do I turn off LTO?
>
> ב-יום שני, 17 ביולי 2023 בשעה 18:51:26 UTC+3, tli...@google.com כתב/ה:
>
>> This error means that some code wasn't compiled with -pthread and
>> therefore is not safe to execute in a multithreaded environment. Normally
>> the error message tells you which object is the culprit, but it's less
>> helpful here because you're using LTO. Does the problem persist if you turn
>> off LTO?
>>
>> On Mon, Jul 17, 2023 at 8:49 AM Ronny Nissengold 
>> wrote:
>>
>>> Hi all!
>>> I am trying to use multithreading in my project.
>>> I got this error when passing -pthread both to compiler and linker.
>>> I am using cmake.
>>> Any idea how to overcome this?
>>> Thanks!
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-disc...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/acbc873e-078a-4082-8761-6c0322246170n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/3c0a9c3c-9e56-41e4-9211-38afba0fc2c2n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EWY7RKRT56ho-JK5%2Bh6nRL_u%3DQxVe8os%2Byv03-Sieei2Q%40mail.gmail.com.

Re: wasm-ld: error: --shared-memory is disallowed by lto.tmp because it was not compiled with 'atomics' or 'bulk-memory' features.

['Thomas Lively' via emscripten-discuss]

This error means that some code wasn't compiled with -pthread and therefore
is not safe to execute in a multithreaded environment. Normally the error
message tells you which object is the culprit, but it's less helpful here
because you're using LTO. Does the problem persist if you turn off LTO?

On Mon, Jul 17, 2023 at 8:49 AM Ronny Nissengold 
wrote:

> Hi all!
> I am trying to use multithreading in my project.
> I got this error when passing -pthread both to compiler and linker.
> I am using cmake.
> Any idea how to overcome this?
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/acbc873e-078a-4082-8761-6c0322246170n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EVbKRUykQyuhYRhQEjMGYBXWtw-QRkxTByr18O%3D5fZYnw%40mail.gmail.com.

Re: Clang driver: can target wasm32 but can’t look up symbols?

['Thomas Lively' via emscripten-discuss]

I’m general I would not expect the standard JIT setup in LLVM to work with
Wasm, even if we solved this particular problem. Even if you could look up
a symbol, you wouldn’t be able to execute it without calling out to the
embedder to first compile and instantiate a Wasm module containing the
code. You would also have to arrange for the function to be placed into the
table so you can get a function pointer to it since Wasm is a Harvard
architecture. This is all possible in principle to implement, but it
definitely will not work out of the box.

On Thu, Jun 8, 2023 at 20:23 Alan Garny  wrote:

> Hi,
>
> Correct, when I build my library for *X86* or *AArch64*, I JIT *X86* and
> *AArch64* code. So, building my library for *wasm32*, I want to JIT
> *wasm32* code.
>
> Regarding your link, yes, I have seen that piece of code when looking for
> the error message I am getting. So, how can I ensure that a code section
> contains only one function symbol in *wasm32* or am I just out of luck?
> (I tried to pass *-ffunction-sections* to the Clang driver, but to no
> avail.)
>
> Alan
>
> On Friday, 9 June 2023 at 12:38:42 UTC+12 s...@google.com wrote:
>
>> When you build for non-wasm platforms are you JIT'ing non-wasm code?
>>
>> This looks like a codegen issue that only affects the wasm backend.   The
>> error in question occurs if a code section contains more than one function
>> symbol.  In the wasm backend we expect every function to get its own
>> section (i.e. -ffunction-sections is always on).   See
>> https://github.com/llvm/llvm-project/blob/6ebf7cd7ed1b6502b3b18985f06b213a53381097/llvm/lib/MC/WasmObjectWriter.cpp#L469-L481
>>
>> On Thu, Jun 8, 2023 at 5:03 PM Alan Garny  wrote:
>>
>>> Hi,
>>>
>>> I have a C++ library that compiles some code
>>> 
>>> on the fly using an ORC JIT and it all works fine when my library is built
>>> for *X86* or *AArch64*, but not when it is built for *wasm32* (using
>>> *wasm32-unknown-unknown-elf* as the target triple). For *wasm32*, it
>>> looks like the code gets compiled but I can't look up its symbols
>>> 
>>>  and
>>> therefore can't run that code.
>>>
>>> In my browser’s console, I am getting:
>>> libopencor.js:8 >>> Compiler::function("initialiseVariables")
>>> libopencor.js:8  - Looking up 'initialiseVariables'...
>>> libopencor.js:8 LLVM ERROR: section already has a defining function:
>>> .text.initialiseVariables
>>> put_char @ libopencor.js:8
>>> libopencor.js:8 Aborted()
>>> abort @ libopencor.js:8
>>> libopencor.js:8 Uncaught (in promise) RuntimeError: Aborted(). Build
>>> with -sASSERTIONS for more info.
>>> at abort (libopencor.js:8:6013)
>>> at _abort (libopencor.js:8:133020)
>>> at libopencor.wasm:0x16693f
>>> at libopencor.wasm:0x2589f4e
>>> at libopencor.wasm:0xd66725
>>> at libopencor.wasm:0x25782f9
>>> at libopencor.wasm:0x1c426bf
>>> at libopencor.wasm:0x25c0cce
>>> at libopencor.wasm:0x296f2b6
>>> at libopencor.wasm:0x9d071b
>>>
>>> I imagine that I must be doing something wrong (when compiling to
>>> *wasm32*), but I can’t tell what it is. I tried to google for some
>>> sample code that does what I am after, but to no avail.
>>>
>>> FWIW, the *wasm32* version of my library is built using Emscripten to 
>>> generate
>>> an ES6 module
>>> 
>>> (using *EXPORT_ES6 *),
>>> making it possible to use my library from both Node.js and from a Web
>>> browser. It all works fine, except for the fact that I cannot look up
>>> symbols and therefore run code that was compiled on the fly.
>>>
>>> So, would anyone have any idea of what I might be doing wrong? The fact
>>> that I am able to do what I want when targeting *X86* or *AArch64* tells
>>> me that I should be able to do the same when targeting *wasm32*...?
>>>
>>> Cheers, Alan.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to emscripten-disc...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/3f08dae1-570e-4cdf-ab37-72b5122c49dfn%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To 

Re: Support for File System Access?

['Thomas Lively' via emscripten-discuss]

There are no concrete plans to implement this, but it has been suggested
before and is similar to work we have done. For any updates, you can follow
the tracking issue we have for this:
https://github.com/emscripten-core/emscripten/issues/12428.

One thing we do hope to do relatively soon is publish an API and
documentation on how to write new WasmFS backends, which should make it
much easier for community members to help out with things like this.

Best,

Thomas

On Mon, Mar 27, 2023 at 3:51 AM 'Dieter Weidenbrück' via emscripten-discuss
 wrote:

> Hi,
> are there any plans to support the File System Access API?
> https://github.com/WICG/file-system-access/blob/main/EXPLAINER.md
>
> For webapps with the need for local file access this API looks very
> useful. For now, it is possible to use it on the JavaScript side and then
> hand things over to C, however, it would be excellent to do all this inside
> Emscripten to have direct access to file contents without copying (in my
> case, files may be large, e.g. several hundred MB).
>
> Thanks for your excellent work!
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/ad965512-998a-4a5e-aaac-1950d41d02e1n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EWQQQsxA-QVYK7YkJtYF%3DYc2uCJXZGZN7fwN_%3DGbT28tQ%40mail.gmail.com.

Re: Support for externref

['Thomas Lively' via emscripten-discuss]

Yes, but note that the usage in that commit is only in hand-written
assembly code, not in C/C++.

More recently, support for externref landed upstream in clang:
https://github.com/llvm/llvm-project/blob/main/clang/test/CodeGen/WebAssembly/wasm-externref.c.
AFAIK we haven't yet experimented with it in Emscripten, but in principle
it should work.

On Fri, Mar 17, 2023 at 10:23 AM Thaina Yu  wrote:

> Is this mean externref already usable?
>
> https://github.com/emscripten-core/emscripten/pull/15913
>
> On Monday, 10 October 2022 at 22:56:34 UTC+7 karl.we...@gmail.com wrote:
>
>> Does anyone have news on this topic?
>>
>> tli...@google.com schrieb am Montag, 25. Januar 2021 um 19:51:36 UTC+1:
>>
>>> I don't think so, but you can keep an eye on commits from "wingo" and
>>> "pmatos" on reviews.llvm.org to keep track of the progress.
>>>
>>> On Mon, Jan 25, 2021 at 12:55 AM ben layet  wrote:
>>>
 Thanks!
 Is there a feature ticket in a publicly visible ticket tracker that I
 can keep an eye on?
 cheers
 ben

 On Saturday, 23 January 2021 at 17:54:25 UTC tli...@google.com wrote:

> Not yet, but there are some folks working on this. Perhaps it will be
> ready to use in a few months? It’s hard to say for sure.
>
> On Sat, Jan 23, 2021 at 03:49 ben layet  wrote:
>
>> Does emscripten support externref reference types for holding opaque
>> handles to JS objects in C++? If not, any idea when?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to emscripten-disc...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/7f6178fa-bd05-4f65-aa7c-9e5a405bf851n%40googlegroups.com
>> 
>> .
>>
> --
 You received this message because you are subscribed to the Google
 Groups "emscripten-discuss" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to emscripten-disc...@googlegroups.com.

>>> To view this discussion on the web visit
 https://groups.google.com/d/msgid/emscripten-discuss/68c9b121-f12f-44fa-a91c-2a8b73d2f456n%40googlegroups.com
 
 .

>>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/57b1491a-7025-4967-a66e-ebcbf10f5e2bn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXCKQdw%2BAKfwKU4wOX_5o%2BzFzCGx9gNw7xDnFexEMx%3Dtg%40mail.gmail.com.

Re: Combining wasms

['Thomas Lively' via emscripten-discuss]

No, unfortunately there's no way to do that today. The closest thing would
be linking in a third party Wasm module in the relocatable .o format, but
standalone Wasm modules are not typically in that format. We may introduce
a wasm-merge tool at some point in the future given that it is a popular
feature request and that there are new emerging toolchains for e.g. Kotlin,
Dart, and Java that are not based on LLVM and cannot produce .o files. I
don't know of anyone currently working on that, though.

You may be interested in wasm-compose from the Bytecode Alliance's
wasm-tools project, although that's focused on composing modules using the
Wasm Component Model, so I don't know if it can handle regular Wasm
modules: https://github.com/bytecodealliance/wasm-tools.

On Mon, Feb 13, 2023 at 10:12 PM craste...@gmail.com 
wrote:

> Is there a way for emscripten to include or merge with an existing wasm
> file?
>
> For example, lets say there is a third party wasm named foo.wasm and I
> want to make a bar.wasm that exposes foo's interface as well as my own bar
> api.
>
> I know that you can include bytecode files in the compile commandline.
> Is there a way to include a wasm file?
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/ff7904e1-c634-4521-8701-2e21c00d69f3n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EW%3DphAF3jTMH%2Bf0xVFhHoi3bde7r7kfhub_g5M0dBRhGQ%40mail.gmail.com.

Re: Async calls - what is the "main thread"?

['Thomas Lively' via emscripten-discuss]

> 1) The "main thread" is the main browser page thread that loaded WASM
webworker, the one with the "window" object. It has access to DOM etc. So
we can use it to work from DOM from C.

This is correct. There is a "proxying" system in Emscripten's system
libraries that handles sending work between threads, but ultimately it is
implemented on top of postMessage. I'm not sure how you looked for
postMessage calls, but if you build with pthreads enabled, they should be
in there somewhere.

On Thu, Feb 9, 2023 at 2:18 AM Ilya Kantor  wrote:

> Hello,
>
> I'm reading the docs and getting confused, what the "Main thread" is?
>
> Sometimes it's referred to as the "Main browser thread", the term appears
> in macroses such as MAIN_THREAD_EM_ASM.
>
> I see two possible explanations there, please tell me which one is correct?
>
> 1) The "main thread" is the main browser page thread that loaded WASM
> webworker, the one with the "window" object. It has access to DOM etc. So
> we can use it to work from DOM from C.
>
> It appears so from the page:
> https://emscripten.org/docs/api_reference/emscripten.h.html?highlight=main_thread_async_em_asm#c.MAIN_THREAD_EM_ASM
>
> But it doesn't work for me like that, and I don't see any `postMessage`
> calls in JS,  how does Emscripten implement the interaction with the main
> page?
>
> 2) The "main thread" is related to pthread usage: it's the all-parenting
> pthread, when we have multiple pthreads running. Otherwise, if we're not
> using pthreads, then it's irrelevant, the main thread is the only thread
> anyway.
>
> In other words, the "main thread" is a pure pthreads concept, the
> all-parenting thread.
>
> 3) ...Can it be sometimes 1) and sometimes 2)? =)
>
> Please help me to figure out.
>
> Thank you!
>
> Kind regards,
> Ilya Kantor
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/029031da-a7f9-47dc-8db0-91a52672e9aan%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EURcypJTd8ONp4JAPAqz06QU5NSfKroDjgpG6FGqhcVEQ%40mail.gmail.com.

Re: [threading] variable has incomplete type 'em_queued_call' (aka 'struct em_queued_call')

['Thomas Lively' via emscripten-discuss]

It looks like there was some unintentional breakage of
`emscripten_sync_run_in_main_thread` in December. I left a comment on the
relevant PR:
https://github.com/emscripten-core/emscripten/pull/15756#issuecomment-1400603196
.

That being said, the best way to send work to other threads these days is
using the proxy queue mechanism in proxying.h
. These new APIs
are safer to use to proxy nontrivial work, give you more control over when
work is executed, and give you more control over how you wait for the work
to be done. FWIW, the older `emscripetn_async_run_in_main_thread` and other
proxying APIs in threading.h have been internally reimplemented in terms of
proxying.h as well.

On Sat, Jan 21, 2023 at 5:16 PM Mark Sibly  wrote:

> I've been using emscripten_async_run_in_main_runtime_thread for 6 months
> or so now and it works great for me.
>
> I do feel this stuff needs to be better docced, emscripten.org has
> nothing about threading in the API reference section, I feel like there
> should at least be a 'threading.h' page in there? There's some useful stuff
> in 'Wasm Workers API' (that's where searching for
> emscripten_async_run_in_main_runtime_thread takes me) although I've need
> used a 'Wasm Worker' so this feels like the wrong place to be looking for
> info on threading.
>
> Bye!
> Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/3b303b63-4008-49f0-bb8b-f48a8c0b294fn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EUaJ%2BWiBT2abCVscMm5WXAGJ35g8jk8p1qOobiGF%3DjKJw%40mail.gmail.com.

Re: wasm-opt is extremely slow

['Thomas Lively' via emscripten-discuss]

That's really slow! Are you using the release binaries or building wasm-opt
yourself? If you're building it yourself, are you sure you're building
wasm-opt in release mode?

Can you run wasm-opt with environment variable BINARYEN_PASS_DEBUG=1 and
share the results? That will show which optimization passes are taking the
most time.

On Mon, Nov 21, 2022 at 1:19 PM Александр Гурьянов 
wrote:

> Hi, I added dosbox-x as backend for js-dos it's size is ~12Mb, wasm-opt
> requires 10-12 min to optimize it (-Oz). Do you have any advice how to
> speed up it? If I build with -O0/1 I have following error in chrome:
>
>
> ‣
> 
>
> CompileError: WebAssembly.compile(): Compiling function 
> #6485:"CPU_Core_Normal_Run()" failed: local count too large @+4790225
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVH02jeZ70pHAe%2BvTL26ScOato8r7b_UBW_V34mJvGwt_Q%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXSn0PmY3GZE4SZAHczJ8U6SekGRB-D5kDfS7c4L9OcKQ%40mail.gmail.com.

Re: The long double

['Thomas Lively' via emscripten-discuss]

I don't believe there is an option to make long double 64 bits, since that
would be an ABI-breaking change. If you're recompiling all your code,
though, I suppose you could use a hack like using a macro to redefine `long
double` to just `double`.

On Fri, Nov 4, 2022 at 2:20 PM Piotr Grochowski <
anydesksuckmehw...@gmail.com> wrote:

>
> sizeof(long double)
> 16
> LDBL_MANT_DIG
> 113
>
> This completely throws me off since I use long double in my code expecting
> it to be native (for example, on Digital Mars on Windows, sizeof(long
> double) is 10, and LDBL_MANT_DIG is 64). And quadruple precision is not
> native in many computers. This certainly should be warned about in
> https://emscripten.org/docs/porting/guidelines/portability_guidelines.html#code-that-compiles-but-might-run-slowly
> . So how do I get long double to be double precision instead (sizeof(long
> double) being 8, and LDBL_MANT_DIG being 53)?
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/23b05bb2-1164-4885-9eb4-cacd7d337f3dn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXUZKf9q3L4SsqXFR4zbFPZY7TQZwvh5ySDr2icKKYuzA%40mail.gmail.com.

Re: Writing and Reading contents to a File asynchronously

['Thomas Lively' via emscripten-discuss]

If the C code and the JS code are running on different threads, this should
work fine. If they are running on the same thread, then the C will need to
return to the event loop to let the JS run at some point. You can use
`emscripten_async_call` to schedule more C code to run again in the future
after the original C code has returned to the event loop.

On Wed, Oct 12, 2022 at 1:07 AM Aitha Tarun  wrote:

> Hi,
> Is it possible to write contents to a file at an indefinite time from
> javascript and read those contents in C code after some amount of time and
> continue this process?
>
> For example, if I write some content from javascript to a shared file at a
> time "t" and want to read that contents in C code at "t+1" time and clear
> those contents from the shared file, and again the javascript code will
> write the contents at "t+2" time and want to read that contents in C code
> at "t+3" time.
>
> Means will the compiled C code (emscripten web assembly)  and our own
> Javascript code can run asynchronously?
>
> *Javascript Code:*
>
> Module.noInitialRun = true;
>
> Module.onRuntimeInitialized = ()=>
> {
> console.log("Initialized");
>
> const stream = Module.FS.open('./events.txt', 'a+');
>
> window.addEventListener
> (
> 'keyup',
> (ev) =>
> {
> if(ev.key === 'p')
> {
> console.log("Writing");
> const output = 'p';
>
> const enc = new TextEncoder();
> enc.encode(output);
>
> const data = enc.encode(output);
>
> Module.FS.write(stream, data, 0, data.length);
> }
> }
> );
>
> Module.callMain();
> }
>
> *C Code:*
>
> #include 
> #include 
>
> int main()
> {
> FILE* ptr;
> char str[50];
>
> ptr = fopen("./events.txt", "r");
>
> if (NULL == ptr)
> {
> printf("Unable to open events file\n");
> return -1;
> }
>
> printf("File contents : \n");
>
> while (fgets(str, 50, ptr) != NULL)
> {
> printf("%s\n", str);
> }
>
> // Perform some operations here
> // And again execute the above reading code after some time
>
> return 0;
> }
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/f0a1a6ae-7c2a-4a97-9124-b5025dcaedd3n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EU2RDO%3DMivJyQCbdqvWugR5N6S7hDAvVj48YoKnz23xkA%40mail.gmail.com.

Re: Overhead of -pthread compiler option?

['Thomas Lively' via emscripten-discuss]

Hi Mark,

If you do that, the output will be roughly the same, but any atomic
accesses you have would still use the atomic instructions. My understanding
is that V8 at least uses the same codegen for atomic instructions no matter
whether the memory is shared or not, so those atomic accesses would be
slower than normal loads and stores. In principle V8 could optimize to use
non-atomic loads and stores in this case, but I don't think it does.
Compiling with threads enabled might also inhibit some optimizations around
those atomic accesses that LLVM would have been able to do otherwise.

If you do end up trying this out, I would be very curious to hear what the
overhead ends up being.

Best,

Thomas

On Wed, Sep 21, 2022 at 7:23 PM Mark Sibly  wrote:

> Hi,
>
> Does anyone have any idea what the overhead of using the -pthread compiler
> option is?
>
> If I'm writing a simple single thread app, is it OK to just leave this on
> for all compilation units, but link the final exe without either -pthread
> or -sPTHREAD_POOL_SIZE? Would this give roughly the same output as
> compiling everything without -pthread?
>
> Bye!
> Mark
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/40ce5767-d11d-4e7e-b44a-247137524b57n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EWKYUgXAfOXFBYLFG384ciWN_DFjDmP%2B0MvtETrkWHrHA%40mail.gmail.com.

Re: WasmFS for jsdos

['Thomas Lively' via emscripten-discuss]

Since WasmFS keeps all of its core data structures (including file
descriptors) in Wasm memory, snapshotting should work for it without
modifications. The only caveat would be that all the backends that use Web
APIs keep state in JS and that state would not be captured by the snapshot,
so you would be constrained to use the in-memory backend only.

On Tue, Aug 2, 2022 at 7:19 PM Александр Гурьянов 
wrote:

> Clear. I remembered another feature that great to have. Will be great if
> FS could make a snapshot of opened files, and restore descriptors on next
> load.
>
> I experimented with snapshotting jsdos. When the user clicks on snapshot,
> then on next asyncify pause jsdos do  dump of wasm memory to file. On next
> page load on same asyncify pause jsdos replaces wasm memory with memory
> from snapshot and resumes.
>
> This work fine until the game need to use fs layer, because opened file
> descriptors became invalid. So, it will be great if new fs layer can
> restore them somehow.
>
> Чт, 28 июля 2022 г. в 03:45, 'Thomas Lively' via emscripten-discuss <
> emscripten-discuss@googlegroups.com>:
>
>> Thanks for the great writeup!
>>
>> >  WasmFS will notify jsdos layer that some file is changed (write/delete
>> etc), so I can schedule update of *second* archive in cloud.
>>
>> Once the core WasmFS system is stable and documented, I hope it will be
>> straightforward to create a custom virtual backend (i.e. a backend that
>> forwards work to another backend) to fire notifications on file
>> modifications.
>>
>> > At the end of extraction you will consume the same amount of memory as
>> the original game size (e.g. 600Mb for CDROM games). ***Unacceptable for
>> mobiles***.
>>
>> This should be possible to fix with WasmFS by streaming files into WasmFS
>> persistent backends like the OPFS backend or a future IndexedDB backend.
>> These backends will never store entire files in memory, unlike IDBFS in the
>> current system. That streaming should be able to use the browser's built-in
>> decompression schemes as well.
>>
>> > I can switch from zip archives to any "bundle/asset" file format* 
>> > introduced
>> by WasmFS*
>>
>> I don't think we have plans to introduce a new data bundle format native
>> to WasmFS, but you can implement your own however you'd like.
>>
>> >  Initially I can download some metafile that contain information about
>> the whole FS. When the dosbox tries to access some file, I will...
>>
>> This sounds like it could be implemented as a read-only backend that
>> fetches data from the network combined with a layering virtual backend that
>> reads missing data from the network backend and writes modifications to a
>> second backend.
>>
>> Overall your planned changes sound like a good match for WasmFS. The core
>> WasmFS backend API is still in flux, but once it is stabilized, we could
>> certainly use help documenting it, providing utilities to make it easy to
>> write new backends from C, C++, or JS, and writing general-purpose virtual
>> backends for caching, layering, notifying on changes, etc.
>>
>> On Wed, Jul 27, 2022 at 10:17 AM Александр Гурьянов 
>> wrote:
>>
>>> I know that WasmFS is in active development, and I want to switch jsdos
>>> to WasmFS.
>>> So, I want to share my use case and if needed help with development.
>>>
>>> jsdos is based on dosbox and it uses POSIX syscalls to access the file
>>> system.
>>>
>>> *dosbox* has the following scenarios accessing files:
>>> * directly accessing files in FS (read/write)
>>> * mounting iso/cue images (CDROM support) (only read)
>>>
>>> *jsdos layer* has additional features:
>>> * storing FS changes in cloud or idbs
>>> * FS compression (currently I use zip)
>>>
>>> jsdos works with zip archives to populate the filesystem. The emulated
>>> program has 2 zip archives:
>>> ***first*** - is a initial game file system
>>> ***second*** - contains changed files.
>>> Before dosbox actually starts, these two "FS archives" are merged into
>>> actual FS.
>>>
>>> Merge implementation is very simple:
>>> 1. Extract *first* archive ***and store modification time of files in
>>> hashtable***.
>>> 2. Extract *second* archive and *overwrite* files
>>>
>>> When jsdos is exited (closed by user) it iterates over FS and checks if
>>> some file have newer
>>> modification time. If so, this file is added to brand new ***second***
>>&g

Re: WasmFS for jsdos

['Thomas Lively' via emscripten-discuss]

Thanks for the great writeup!

>  WasmFS will notify jsdos layer that some file is changed (write/delete
etc), so I can schedule update of *second* archive in cloud.

Once the core WasmFS system is stable and documented, I hope it will be
straightforward to create a custom virtual backend (i.e. a backend that
forwards work to another backend) to fire notifications on file
modifications.

> At the end of extraction you will consume the same amount of memory as
the original game size (e.g. 600Mb for CDROM games). ***Unacceptable for
mobiles***.

This should be possible to fix with WasmFS by streaming files into WasmFS
persistent backends like the OPFS backend or a future IndexedDB backend.
These backends will never store entire files in memory, unlike IDBFS in the
current system. That streaming should be able to use the browser's built-in
decompression schemes as well.

> I can switch from zip archives to any "bundle/asset" file format* introduced
by WasmFS*

I don't think we have plans to introduce a new data bundle format native
to WasmFS, but you can implement your own however you'd like.

>  Initially I can download some metafile that contain information about
the whole FS. When the dosbox tries to access some file, I will...

This sounds like it could be implemented as a read-only backend that
fetches data from the network combined with a layering virtual backend that
reads missing data from the network backend and writes modifications to a
second backend.

Overall your planned changes sound like a good match for WasmFS. The core
WasmFS backend API is still in flux, but once it is stabilized, we could
certainly use help documenting it, providing utilities to make it easy to
write new backends from C, C++, or JS, and writing general-purpose virtual
backends for caching, layering, notifying on changes, etc.

On Wed, Jul 27, 2022 at 10:17 AM Александр Гурьянов 
wrote:

> I know that WasmFS is in active development, and I want to switch jsdos to
> WasmFS.
> So, I want to share my use case and if needed help with development.
>
> jsdos is based on dosbox and it uses POSIX syscalls to access the file
> system.
>
> *dosbox* has the following scenarios accessing files:
> * directly accessing files in FS (read/write)
> * mounting iso/cue images (CDROM support) (only read)
>
> *jsdos layer* has additional features:
> * storing FS changes in cloud or idbs
> * FS compression (currently I use zip)
>
> jsdos works with zip archives to populate the filesystem. The emulated
> program has 2 zip archives:
> ***first*** - is a initial game file system
> ***second*** - contains changed files.
> Before dosbox actually starts, these two "FS archives" are merged into
> actual FS.
>
> Merge implementation is very simple:
> 1. Extract *first* archive ***and store modification time of files in
> hashtable***.
> 2. Extract *second* archive and *overwrite* files
>
> When jsdos is exited (closed by user) it iterates over FS and checks if
> some file have newer
> modification time. If so, this file is added to brand new ***second***
> archive.
>
> The ***second*** archive can be stored in idbfs, or in cloud.
>
> *This solution has practical problems:*
> *1*. zip is slow when extracting files. Not dramatically, but it will be
> much better to use native decoder of the browser (gzip/brotli).
> *2*. I can say zip compression rate ***is good enough*** for most games.
> But you* can't extract *big games on mobiles. It results in OOM. To
> extract you need to download the whole archive (*1st copy*), put it into
> WASM memory (*2st copy*) and keep it while it is extracting.
> *3*. At the end of extraction you will consume the same amount of memory
> as the original game size (e.g. 600Mb for CDROM games). ***Unacceptable
> for mobiles***.
> *4*. There is no option in emscripten FS to notify jsdos when some file
> is changed, because of that storing changes is triggered manually when the
> user closes the jsdos window. BUT, most users just ***closes the browser
> tab and lost all progress.***
> *5*. The ***second*** archive can't handle deletion of files. If some
> file is deleted it will be there on the next run. It's because there is no
> marker in the zip to signal that some file needs to be deleted. However,
> for jsdos this happens very rarely and can be ignored.
>
> *WasmFS ideas:*
> *1*. WasmFS will notify jsdos layer that some file is changed
> (write/delete etc), so I can schedule update of *second* archive in cloud.
> *2*. I can switch from zip archives to any "bundle/asset" file format*
> introduced by WasmFS*. Initially I can download some metafile that
> contain information about the whole FS. When the dosbox tries to access
> some file, I will:
>
> * stop execution with asyncify
> * lookup in meta which FS block need to be downloaded
> * download it (with progress indication)
> * mount it
> * resume execution
>
> I imagine that we can use gzip/brotli *browser decoder* here.
> I think this flow is more or less generic and can 

Re: Using shared memory (-s IMPORTED_MEMORY=1)

['Thomas Lively' via emscripten-discuss]

Also note that you probably do want to use atomic operations to read and
write to the shared memory, even if you're using JS on one thread and Wasm
on another. If you don't use atomics, there's no guarantee that the values
written on one thread will actually become visible on the other thread when
you expect them to.

On Fri, Mar 4, 2022 at 11:49 AM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> Historically the `-pthead` flag (or `-s USE_PTHREADS`) is the way to get
> shared memory.   Is there some reason you have not wanted to use that
> flag?  (is it code size
> of the resulting JS.. if so we are working on reducing that).
>
> As it happens we just today landed a new `-s SHARED_MEMORY` flag I think
> gives you exactly what you want without the overhead of the pthread JS
> library code: https://github.com/emscripten-core/emscripten/pull/16419.
>
> cheers,
> sam
>
> On Fri, Mar 4, 2022 at 10:29 AM Александр Гурьянов 
> wrote:
>
>> https://github.com/WebAssembly/binaryen/pull/4525
>>
>>
>> пт, 4 мар. 2022 г. в 15:43, Александр Гурьянов :
>>
>>> Hi, I want to use shared memory for my WebAssembly module. It's needed
>>> for js-dos. Currently emulation works in worker and frame updates are send
>>> using postMessage. I want to use SharedArrayBuffer to avoid copying/sending
>>> big rgba data.
>>>
>>> I dont' need to use pthread or threading, I just want to share memory
>>> between worker and main process. How I can say emscripten to generate
>>> "shared" memory imort.
>>>
>>> I found similar question here:
>>> https://github.com/emscripten-core/emscripten/issues/12098
>>> As suggested I tried wasm2wat and then wat2wasm, but it not working for
>>> me. Looks like it affects  -s INVOKE_RUN=0, because after wasm2wat my
>>> module immediately starts and I can't provide own memory.
>>>
>>> Without wasm2wat I have this error:
>>>
>>> LinkError: WebAssembly.instantiate(): mismatch in shared state of
>>> memory, declared = *0*, imported = *1*
>>>
>>> After wasm2wat this:
>>>
>>> LinkError: WebAssembly.instantiate(): mismatch in shared state of
>>> memory, declared = *1*, imported = *0*
>>>
>>> Can we add some pass to binaryen for turning non-shared memory into
>>> shared?
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVE24Q4%2Bewi5QBSdmuuRf7F-FCk_1TM7tZxexwrMOzXdqw%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_UWBhM-2yOG_6aUDPa_%3DX%3DmDJOxaC00Bo8CbQa6cDbYw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EWNu%3Di0%3DACiKbuPyTOUAckT1SDceosApBvJj6VCo8-WYQ%40mail.gmail.com.

Re: Facebook/Meta's "Bolt" optimizer for WebAssembly target

['Thomas Lively' via emscripten-discuss]

Yes, good point. The branch hinting proposal has a very similar goal. And
yes, outlining cold blocks into separate functions has downsides, but as V8
(and maybe other engines?) move to lazy tier-up, the outlining can improve
startup performance get reach peak performance sooner by reducing the
amount of code that needs to be tiered up.

I know PGO is on our list of things we'd like to get to eventually, but I
don't think we have any specific plans to work on it soon.

On Wed, Jan 12, 2022 at 10:14 PM Soeren Balko  wrote:

> Interesting, as I understand branch hinting is already WebAssembly
> proposal that is being worked on. Perhaps it could be use to segregate away
> the "cold" blocks (branches). Moving cold blocks into functions (as the
> only existing modularization concept in wasm) seems quite complex and
> possibly introduce a performance penalty when calling cold code. Also, I
> wonder if the (tiered) WebAssembly runtimes would even be smart enough to
> treat hot functions differently from cold ones. But I am really out of my
> depth here, not sure if any of this makes sense.
>
> In a more general sense: Emscripten once had PGO, which now seems to be
> deprecated (is it?). Are there any plans to bring it back? We've got some
> very specific workloads, for which we have performance profiles that we'd
> love to feed back into the build process.
>
> Soeren
>
>
>
> On Wednesday, January 12, 2022 at 6:27:38 PM UTC+10 tli...@google.com
> wrote:
>
>> IIRC, Bolt reorganizes binaries to separate out cold blocks into separate
>> code sections. A similar optimization would probably be useful in
>> WebAssembly, but it would have to outline the cold blocks into separate
>> functions. Alternatively, we could add some sort of hinting about cold
>> blocks in a custom section and let the WebAssembly engine perform this
>> optimization on the compiled code.
>>
>> On Wed, Jan 12, 2022 at 01:32 Soeren Balko  wrote:
>>
>>> The good people at Facebook just landed their "Bolt" optimizer in LLVM:  
>>> llvm-project/bolt
>>> at main · llvm/llvm-project (github.com)
>>> 
>>>
>>> Bolt is currently limited to x86-64 and AArch64. Given the lofty
>>> performance uplift that Bolt claims to deliver, I wonder if WebAssembly
>>> would benefit from it. Any thoughts?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-disc...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/1cd76c9b-7ea9-4fd4-9678-72b080204f5an%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/1d700f91-ad66-426a-a31f-305970c1d80an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EUdasBD1mJvyk%2B%2BXvMFE2m7vKHbr_RdfTW304_F2CTzow%40mail.gmail.com.

Re: Facebook/Meta's "Bolt" optimizer for WebAssembly target

['Thomas Lively' via emscripten-discuss]

IIRC, Bolt reorganizes binaries to separate out cold blocks into separate
code sections. A similar optimization would probably be useful in
WebAssembly, but it would have to outline the cold blocks into separate
functions. Alternatively, we could add some sort of hinting about cold
blocks in a custom section and let the WebAssembly engine perform this
optimization on the compiled code.

On Wed, Jan 12, 2022 at 01:32 Soeren Balko  wrote:

> The good people at Facebook just landed their "Bolt" optimizer in LLVM:  
> llvm-project/bolt
> at main · llvm/llvm-project (github.com)
> 
>
> Bolt is currently limited to x86-64 and AArch64. Given the lofty
> performance uplift that Bolt claims to deliver, I wonder if WebAssembly
> would benefit from it. Any thoughts?
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/1cd76c9b-7ea9-4fd4-9678-72b080204f5an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EX86qYniowqZVABcLnuprQNf6V_iwWeHF6n7p9parfQ2A%40mail.gmail.com.

Re: New LLVM 14 performance optimization

['Thomas Lively' via emscripten-discuss]

I don’t know about this new LICM optimization in particular, but I can tell
you that Binaryen and wasm-opt specifically are completely separate from
LLVM, so do not share any LICM code with it. emcc -O3 is also just a
wrapper around clang -O3, so it should run the same optimizations that
vanilla clang would. I hope that helps you make sense of things!

On Wed, Jan 12, 2022 at 01:26 Soeren Balko  wrote:

> So I just installed the emsdk "top of tree" that comes with LLVM 14. Turns
> out that gives me some ~5% performance improvement in some workloads (HEVC
> decoding with FFmpeg, which was already hand-optimised to use WebAssembly
> SIMD intrinsics). Which is great - if only I knew where that's coming
> from...
>
> Specifically, what is not clear to me is the following:
>
> (1) Is the new load hoisting optimization automatically performed as part
> of LLVM/s LICM pass? That's probably more a question to the LLVM peeps and
> I assume that that's a "yes".
> (2) Does the "licm" pass in Binaryen's wasm-opt use LLVM's "licm" pass?
> (3) Does emcc -O3 already include wasm-opt's "licm" pass? I added -s
> BINARYEN_EXTRA_PASSES=licm, but that didn't seem to have an effect.
>
> I tried directly invoking LLVM's LICM optimisation by passing -mllvm -licm
> to emcc, but that makes emcc error out. Interestingly, -mllvm
> -enable-loop-versioning-licm does work, but seems to be an entirely
> different optimization altogether.
>
> Sadly, the interplay of emcc, clang, wasm-opt, and LLVM's opt utility
> isn't all too clear when it comes to non-standard clang/LLVM features...
>
> Soeren
>
> On Wednesday, December 8, 2021 at 3:25:48 AM UTC+10 alon...@gmail.com
> wrote:
>
>> Looks like that patch landed Dec 2, so it is already in the latest tip of
>> tree build of emscripten, which people can try with
>>
>> emsdk install tot
>>
>>
>>
>> On Tue, Dec 7, 2021 at 5:52 AM 'Thomas Lively' via emscripten-discuss <
>> emscripte...@googlegroups.com> wrote:
>>
>>> Yes, from the description in that article I would expect that
>>> optimization to apply to the Wasm target as well.
>>>
>>> Thomas
>>>
>>> On Mon, Dec 6, 2021 at 20:04 Soeren Balko  wrote:
>>>
>>>> Saw this today:  LLVM Clang 14 Lands An "Amazing" Performance
>>>> Optimization - Phoronix
>>>> <https://www.phoronix.com/scan.php?page=news_item=LLVM-Clang-14-Hoist-Load>
>>>>
>>>> Looks like a fairly substantial gain for some workloads. Will this also
>>>> apply to the WebAssembly target?
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "emscripten-discuss" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to emscripten-disc...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/emscripten-discuss/243b4dc8-4305-4af5-9e9d-dff8c0e84c4bn%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/emscripten-discuss/243b4dc8-4305-4af5-9e9d-dff8c0e84c4bn%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-disc...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXyXLJ6-db5tUrgQzmN5QPsV0S0%3DbPub-TZA1BgrjWnjw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXyXLJ6-db5tUrgQzmN5QPsV0S0%3DbPub-TZA1BgrjWnjw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/f9b4c9a7-92aa-4b3c-b092-8c794693b626n%40googlegroups.com
> <https://groups.google.com/d/msgid/emscripten-discuss/f9b4c9a7-92aa-4b3c-b092-8c794693b626n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EVsg07uzWQ_bJ%2BtJ9LRjdpPC01duLFeOReVu08TGe%3DX0w%40mail.gmail.com.

Re: New LLVM 14 performance optimization

['Thomas Lively' via emscripten-discuss]

Yes, from the description in that article I would expect that optimization
to apply to the Wasm target as well.

Thomas

On Mon, Dec 6, 2021 at 20:04 Soeren Balko  wrote:

> Saw this today:  LLVM Clang 14 Lands An "Amazing" Performance
> Optimization - Phoronix
> 
>
> Looks like a fairly substantial gain for some workloads. Will this also
> apply to the WebAssembly target?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/243b4dc8-4305-4af5-9e9d-dff8c0e84c4bn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXyXLJ6-db5tUrgQzmN5QPsV0S0%3DbPub-TZA1BgrjWnjw%40mail.gmail.com.

Re: Enabling tail calls

['Thomas Lively' via emscripten-discuss]

Hmm, I tried finding documentation on -menable-tail-call or an
implementation of it but couldn't, so then I tried using it to see if it
did anything. I built the in-tree sqlite benchmark at -O2 with no extra
flags, with -mtail-call, and with -menable-tail-call. The version built
with -mtail-call contained 53 instances of `return_call` or
`return_call_indirect` instructions, but the version with no flags and the
version with -menable-tail-call were identical. I also confirmed that
Emscripten does not warn or error out on unknown flags passed at link time,
so I can only conclude that -menable-tail-call is not a real flag. The
performance difference you saw must have been noise.

On Wed, Nov 24, 2021 at 12:00 AM Soeren Balko  wrote:

> Thanks Thomas - haven't run into any issues. There wasn't any measurable
> performance uplift when using -mtail-call though, which is probably
> because my workload (FFmpeg) may not use it much.
>
> That being said, I previously played around with the -menable-tail-call
> linker flag. And unlike -mtail-call, it does two things: firstly, it does
> produce a small (~1%), but consistent performance uplift. At the same time,
> it doesn't seem to make use of the new WebAssembly opcodes (didn't require
> me to enable those in V8). Not sure what -menable-tail-call actually
> does, but it seems different from -mtail-call. Also, it cannot be used as
> a compiler flag, ie. only the linker will accept it.
>
> Any ideas?
>
> Soeren
>
> On Wednesday, November 24, 2021 at 10:57:46 AM UTC+10 tli...@google.com
> wrote:
>
>> Hi Soeren,
>>
>> The compiler flag -mtail-call is what you want. This support has been in
>> upstream LLVM for a while, but it hasn't been used very much, so if you run
>> into bugs with it, please let us know!
>>
>> Best,
>>
>> Thomas
>>
>> On Tue, Nov 23, 2021 at 6:14 PM Soeren Balko 
>> wrote:
>>
>>> I was wondering about the state of WebAssembly tail call support in
>>> Emscripten. It's available as an experimental V8 feature in Chrome and will
>>> hopefully be mainstreamed in the not-too distant future.
>>>
>>> Couldn't find much information on how to build with tail call support in
>>> Emscripten, but I suspect that adding the -menable-tail-call linker
>>> flag does the trick? Or is there more to it?
>>>
>>> @Alon - can you please confirm?
>>>
>>> Thank you!
>>> Soeren
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-disc...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/bdcc8072-b7a0-454c-bd05-68b0ae780c77n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/f697836d-10ef-41a0-85bb-565698302427n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EUTsDzuySLy3U_tcYitL9f-%3D5AsKCbn243Y8w0SgANzbg%40mail.gmail.com.

Re: Enabling tail calls

['Thomas Lively' via emscripten-discuss]

Hi Soeren,

The compiler flag -mtail-call is what you want. This support has been in
upstream LLVM for a while, but it hasn't been used very much, so if you run
into bugs with it, please let us know!

Best,

Thomas

On Tue, Nov 23, 2021 at 6:14 PM Soeren Balko  wrote:

> I was wondering about the state of WebAssembly tail call support in
> Emscripten. It's available as an experimental V8 feature in Chrome and will
> hopefully be mainstreamed in the not-too distant future.
>
> Couldn't find much information on how to build with tail call support in
> Emscripten, but I suspect that adding the -menable-tail-call linker flag
> does the trick? Or is there more to it?
>
> @Alon - can you please confirm?
>
> Thank you!
> Soeren
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/bdcc8072-b7a0-454c-bd05-68b0ae780c77n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXxUOTnzv08hUY-xsQB5HZTaRFnrZVF_W%2B_d2cDraS7AA%40mail.gmail.com.

Re: Regarding WASM build

['Thomas Lively' via emscripten-discuss]

Hi Giri,

you may want to look into using a build system rather than specifying all
your source files in a single command. I would recommend using Make to
start because it is relatively simple. This page looks like a good
introduction to it:
https://www.cs.colby.edu/maxwell/courses/tutorials/maketutor/.

Make will let you speed up your builds by building multiple source files in
parallel and by only re-building source files that have changed since your
last build.

Best,

Thomas

On Tue, Jun 22, 2021 at 3:39 AM Velliyangiri A <
velliyangiri2029...@gmail.com> wrote:

> Dear all,
>
> I have many .c files like hello1.c, hello2.c, etc. All the files are
> dependent to one project.
> So I want to compile all the files and build a .wasm file.
> For compilation, I have specified all the .c files manually in emcc
> command line like
>
> emcc -g  hello1.c hello2.c hello3.c -s WASM=1 -s EXPORT_ALL=1 -o hello.js
> -s FORCE_FILESYSTEM=1 -s "EXPORTED_RUNTIME_METHODS=['calls','cwrap']" -s
> "EXPORTED_FUNCTIONS=['_Hello']" -s ALLOW_MEMORY_GROWTH=1
>
> Is there any way available to load all the .c files without specifying
> manually in the command line?
> Kindly help me.
>
> Referred links
>
>1.
>https://developer.mozilla.org/en-US/docs/WebAssembly/existing_C_to_wasm
>
>2. https://emscripten.org/docs/compiling/Building-Projects.html
>
> Thanks and Regards,
> Giri
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/e83551e1-ae66-4195-8e58-709991c4e59bn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EUSRuVGwigrdtTvqTv0HhLgm9%2BGDOPpYrft%3DbT2tPxSSQ%40mail.gmail.com.

Re: Pre-initialize with Wizer

['Thomas Lively' via emscripten-discuss]

I believe Emscripten used to have a similar feature, but we had to disable
it because it turned out that we depended on JS setting some values in
memory before running the Wasm code and the pre-evaluation tool couldn’t
account for that. I’m not sure whether that situation has changed, though.

On Fri, Jun 18, 2021 at 21:51 Dan C  wrote:

> Hi everyone,
>
> I recently came across this tool https://github.com/bytecodealliance/wizer,
> which doesn't seem designated for Emscripten. I'm wondering whether anyone
> had any luck with it.
>
> Thanks,
> Dan
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/f8abb27a-95b6-458c-bac9-35a9be0c31cfn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXGyjh_h8VVQ5y9Qza2V5m1D97M2Bh8tGM5AyhfDpYBhg%40mail.gmail.com.

Re: wasm-split to multiple modules

['Thomas Lively' via emscripten-discuss]

Yes, the code pattern you suggest should be able to split off each function
into a separate module without any problems. I would recommend configuring
a different `placeholderNamespace` for each module you split off to make it
easy to tell which module you will need to instantiate to get the proper
replacement. In principle you could also do this by invoking wasm-split
multiple times instead of writing a custom tool. If you want to continue
tracking calls after the replacement module has been instantiated, you
should do that using a separate mechanism rather than using wasm-split's
placeholder functions, since it's a core assumption of wasm-split that the
placeholder functions will be entirely replaced.

Do note that Emscripten has no support for this kind of custom splitting,
so you'll be on your own for making the JS load and instantiate the
individual modules at runtime.


On Wed, Apr 21, 2021 at 3:56 AM Александр Гурьянов 
wrote:

> Hi.I have a custom optimization layer that helps me to decrease wasm
> binary size. It is a sort of PGO optimization, I have a statistic about
> each function in wasm - how many times it called. Then I remove functions
> with zero invocations from wasm and generate js version of same function to
> invoke if it suddenly needed (1 js file - 1 removed function). This
> optimization works very good except it uses js which is slow and big.
>
> Now I want to generate small wasm modules (<4Kb) instead of js versions. I
> thought that wasm-split can help, but I realized that it generates a big
> module that can't be load in synchronous way. Moreover there is another
> problem, it replaces all placeholders with actual implementation on
> instantiation. But, I don't want to replace placeholders because they
> continue to track call stats (this is minor problem, I know workaround for
> it).
>
> Is there some way to force wasm-split to generate multiple modules (1 per
> function). Something like this:
>
>   std::unique_ptr fn1 =
> ModuleSplitting::splitFunctions(wasm, );
>   std::unique_ptr fn2 =
> ModuleSplitting::splitFunctions(wasm, );
>
> ...
>
>   ModuleWriter writer;
>   writer.setBinary(options.emitBinary);
>   writer.setDebugInfo(options.passOptions.debugInfo);
>   writer.write(wasm, options.primaryOutput);
>   writer.write(*fn1, wasmFn1);
>   writer.write(*fn2, wasmFn2);
>
> Or if it's not possible, what do you think is it doable and how hard is it?
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVGzr8Wr_MR4733AkKnkkyoq2ainU6kzsS9dOkVuXki7NQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXryerDjOZD%3DjmF3eh%3DKERJLYJ4ysd%2BuRc7L-E97u6jxQ%40mail.gmail.com.

Re: Using custom libs .a files

['Thomas Lively' via emscripten-discuss]

Hi Mehaboob,

No, Emscripten cannot compile native objects or archive files to
WebAssembly. Perhaps what you saw was a reference to archive files
containing WebAssembly objects produced by Emscripten?

Thomas

On Wed, Apr 14, 2021 at 12:45 Mehaboob kk  wrote:

> Hello All,
>
> I see that Emscripton allows to compile .a files to wasm. In order for
> this to work the .a file need to be originally compiled using gcc? if yes,
> any specific version to be compatible?
>
> Thanks,
> Mehaboob
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/ee46348f-db22-406d-b85d-7dae3aa57e8an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EUz2Mkh3S1%2Bh7iGox2Pk3KZWOvMKOrr8a7sNSoZyG7rnw%40mail.gmail.com.

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

['Thomas Lively' via emscripten-discuss]

That's the link command, since Driver.o is one of the inputs. You need to
pass -pthread at compile time, where Driver.o is created, as well.

On Thu, Apr 8, 2021 at 1:26 PM Jasmeet Kaur  wrote:

> I am using -pthread flag : (makefile)
> COMMON_LNFLAGS += -Lapps/libs -Ldemos/libs -L/usr/X11R6/lib64
> -L/usr/X11R6/lib -pthread
>
> and here is the compilation output :
>
>
> *emcc  -o ../../../../html/debug/snakebird.js
> ../../../../objs_html/snakebird.js/debug/apps/snakebird/Driver.o
> -lenvironments -lmapalgorithms -lalgorithms -lgraphalgorithms -lgraph
> -lutils -lguihtml -lgui -lSTUB -L../../../../html/debug -Lapps/libs
> -Ldemos/libs -L/usr/X11R6/lib64 -L/usr/X11R6/lib -pthread -g -s
> EXPORTED_FUNCTIONS="['_InitHOG', '_InitHOGArg', '_DoFrame', '_MouseEvent',
> '_HitKey', '_SetCanvasSize']" -s
> EXTRA_EXPORTED_RUNTIME_METHODS=["cwrap"]Live child 0x5633c6243c40
> (../../../../html/debug/snakebird.js) PID 22723 wasm-ld: error:
> --shared-memory is disallowed by
> ../../../../objs_html/snakebird.js/debug/apps/snakebird/Driver.o because it
> was not compiled with 'atomics' or 'bulk-memory' features.*
>
> Is this not correct?
>
> On Thursday, April 8, 2021 at 4:17:10 PM UTC-4 tli...@google.com wrote:
>
>> The object file specified in the error message was not compiled with
>> -pthread, so atomic operations and thread-local data (if any) in its source
>> were transformed to non-atomic operations and non-thread-local data. That
>> transformation makes it unsafe to link that object into multi-threaded
>> programs, so wasm-ld fails with that error message. The fix is to use
>> -pthread when compiling that object.
>>
>> On Thu, Apr 8, 2021 at 1:11 PM Jasmeet Kaur  wrote:
>>
>>> Hi,
>>> I am trying to use emscripton for a project. When I compile,  I get this
>>> error :
>>> wasm-ld: error: --shared-memory is disallowed by  because it was not
>>> compiled with 'atomics' or 'bulk-memory' features.
>>> Can someone point me as to how to resolve this? And also explain as to
>>> why is this happening?
>>> Environment info;
>>>
>>>
>>>
>>>
>>> *emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld)
>>> 2.0.16clang version 13.0.0
>>> (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project
>>> ad8010e598d9aa3747c34ce28aa2ba6de1650bd4)Target:
>>> wasm32-unknown-emscriptenThread model: posix*
>>>
>>> Thank you!
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-disc...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/a9d08d47-9808-4205-bb71-e9990aa19cf7n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/83625760-2cf9-4185-95cf-b52ba0a5ab85n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EVySrEEkqKF36s95D8tHPu9j%2BX94w9dFOi_OdQnKbve_w%40mail.gmail.com.

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

['Thomas Lively' via emscripten-discuss]

The object file specified in the error message was not compiled with
-pthread, so atomic operations and thread-local data (if any) in its source
were transformed to non-atomic operations and non-thread-local data. That
transformation makes it unsafe to link that object into multi-threaded
programs, so wasm-ld fails with that error message. The fix is to use
-pthread when compiling that object.

On Thu, Apr 8, 2021 at 1:11 PM Jasmeet Kaur  wrote:

> Hi,
> I am trying to use emscripton for a project. When I compile,  I get this
> error :
> wasm-ld: error: --shared-memory is disallowed by  because it was not
> compiled with 'atomics' or 'bulk-memory' features.
> Can someone point me as to how to resolve this? And also explain as to why
> is this happening?
> Environment info;
>
>
>
>
> *emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld)
> 2.0.16clang version 13.0.0
> (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project
> ad8010e598d9aa3747c34ce28aa2ba6de1650bd4)Target:
> wasm32-unknown-emscriptenThread model: posix*
>
> Thank you!
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/a9d08d47-9808-4205-bb71-e9990aa19cf7n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EV_CT-Ld9%2BG96WBRvDHLK2deO%2BJ%2BXJVYxgsS46RFuLe5Q%40mail.gmail.com.

Re: if (!this) is allowed?

['Thomas Lively' via emscripten-discuss]

I’m pretty sure that calling a method on a null pointer is undefined
behavior. My guess is that at some point LLVM started recognizing and
optimizing away this UB, which is why you’re seeing different behavior with
newer versions of Emscripten.

On Wed, Feb 24, 2021 at 22:57 Александр Гурьянов 
wrote:

> Hi, I have a big code base that uses this pattern:
>
> ```
>
> int String::intValue() const {
> if (!this) {
> return 0;
> }
>
>// ...
> }
>
> int count = dict->stringForKey("count")->intValue();
>
> ```
>
> If *dict->stringForKey* returns *nullptr* then wasm is crashed, but
> native works fine.
> This code also worked fine with old versions of emscipten.
>
> I understand that this is ugly pattern, but I am curious if it can work as
> before?
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVF2kSJEthLuvS7afsPFprxehG%3DXJxppdHxMA6a8rvUyAw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EWr1ZkGVzXLWVHf9FGK137UUUZut%3Dce5GbbOU-FLLUXbA%40mail.gmail.com.

Re: Dealing with "Maximum call stack size exceeded" on fsanitize=undefined

['Thomas Lively' via emscripten-discuss]

I have a fix up for review:
https://github.com/emscripten-core/emscripten/pull/13367

On Tue, Jan 26, 2021 at 9:09 AM 'Maksim Ivanov' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> Thanks, Thomas.
>
> As this is a confirmed issue now, I went ahead and created an issue to
> track it: https://github.com/emscripten-core/emscripten/issues/13324
>
>
> Maksim
>
>
> On Mon, Jan 25, 2021 at 8:58 PM 'Thomas Lively' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> Thanks, I am able to reproduce the issue locally. Looking into it now.
>>
>> On Thu, Jan 21, 2021 at 7:15 PM 'Maksim Ivanov' via emscripten-discuss <
>> emscripten-discuss@googlegroups.com> wrote:
>>
>>> The minimized repro is:
>>>
>>> #include 
>>> #include 
>>> class A final {
>>>  public:
>>>   MOCK_METHOD0(Foo, void());
>>> };
>>> TEST(Some, DISABLED_Basic) {
>>>   A a;
>>>   EXPECT_CALL(a, Foo());
>>> }
>>>
>>> Googletest/mock are 1.10.0.
>>>
>>>
>>> Maksim
>>>
>>>
>>> On Fri, Jan 22, 2021 at 1:07 AM Maksim Ivanov  wrote:
>>>
>>>> Thanks, Alon.
>>>> I added this flag and, indeed, it's an infinite recursion.
>>>>
>>>> I'll update this thread once I have a minimized repro sample to share.
>>>>
>>>>
>>>> Maksim
>>>>
>>>>
>>>> On Fri, Jan 22, 2021 at 12:06 AM Alon Zakai 
>>>> wrote:
>>>>
>>>>> Different versions of node may truncate the stack to different
>>>>> defaults. But it is configurable, try
>>>>>
>>>>> node --stack-trace-limit=1000
>>>>>
>>>>> On Thu, Jan 21, 2021 at 2:53 PM 'Maksim Ivanov' via emscripten-discuss
>>>>>  wrote:
>>>>>
>>>>>> @Alon: Hard to say whether it's an infinite recursion - the snippet I
>>>>>> attached is all what's output. Can it be that something truncates the 
>>>>>> stack
>>>>>> before printing, without leaving any trace of what was truncated?
>>>>>> My other hypothesis was that some code generated by UBSan allocates
>>>>>> huge variables on stack; again, I don't know how to verify that.
>>>>>>
>>>>>> @Thomas: Sure; I'll probably be able to do it in a couple of days,
>>>>>> after minimizing the repro and removing irrelevant details from it.
>>>>>>
>>>>>>
>>>>>> Maksim
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 21, 2021 at 11:49 PM 'Thomas Lively' via
>>>>>> emscripten-discuss  wrote:
>>>>>>
>>>>>>> I've seen reports of infinite recursions involving
>>>>>>> __ubsan_handle_dynamic_type_cache_miss before, but I've never been able 
>>>>>>> to
>>>>>>> reproduce them to investigate. Would you be able to share your 
>>>>>>> reproducer?
>>>>>>>
>>>>>>> On Thu, Jan 21, 2021 at 2:24 PM Alon Zakai 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Does the stack trace look like it's an infinite recursion? That
>>>>>>>> could be a toolchain bug.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jan 20, 2021 at 11:58 AM 'Maksim Ivanov' via
>>>>>>>> emscripten-discuss  wrote:
>>>>>>>>
>>>>>>>>> Hello, does anyone have a tip on how to work around the "Maximum
>>>>>>>>> call stack size exceeded" error when running a UBsan-sanitized 
>>>>>>>>> Emscripten
>>>>>>>>> program under Node?
>>>>>>>>>
>>>>>>>>> The error is:
>>>>>>>>>
>>>>>>>>> "RangeError: Maximum call stack size exceeded
>>>>>>>>> at _emscripten_return_address (a.out.js:6788:35)
>>>>>>>>> at __ubsan_handle_dynamic_type_cache_miss
>>>>>>>>> (wasm-function[8220]:0x210eb3)
>>>>>>>>> at std::type_info::operator==(std::type_info const&) const
>>>>>>>>> (wasm-function[938]:0x648b3)
>>>>>>>>> 

Re: Emscripten compilation works really slow on web browsers.

['Thomas Lively' via emscripten-discuss]

Yes, recompiling with -pthread is certainly something you can play around
with. You will probably need to compile all or none of the code with
-pthread, rather than just some of it.

On Thu, Jan 28, 2021 at 02:10 Adam Wnęk  wrote:

> Hi
>
> Thanks for advice. I will check this on DevTools. Right now quick grep
> search in library src files shows, that there are pthread header included
> in several files.
>
> Should I add -pthread flag for compilation of my code? Should i recompile
> libraries with -pthread flag?
>
> Regards
>
> Adam
> W dniu 28.01.2021 o 00:09, 'Thomas Lively' via emscripten-discuss pisze:
>
> Ok, thanks for verifying. I'm not familiar with the libraries you're
> using. Do they use SIMD or multithreading in the native versions? That
> could be a source of large slowdowns if you're not using those features in
> the WebAssembly version. You also might want to profile your application in
> Chrome's DevTools to see where it is spending its time and compare that to
> a profile of the native build.
>
> On Wed, Jan 27, 2021 at 1:22 PM Adam Wnęk  wrote:
>
>> Hi,
>>
>> I have checked once again. My previous snapshot  from make output was
>> without optimization indeed (different configuration)
>>
>> Right  one looks like that:
>>
>> /home/adam/Temp/emsdk/upstream/emscripten/em++  -DOCC_CONVERT_SIGNALS
>> @CMakeFiles/cadModelConverter.dir/includes_CXX.rsp -s WASM=1 -s
>> ALLOW_MEMORY_GROWTH=1 -DNDEBUG -O2   -std=gnu++11 -o
>> CMakeFiles/cadModelConverter.dir/fileconverter.cpp.o -c
>> /home/adam/projects/EmscriptenProjects/CadModelConverter/fileconverter.cpp
>>
>>
>> /home/adam/Temp/emsdk/upstream/emscripten/em++  -DOCC_CONVERT_SIGNALS
>> @CMakeFiles/cadModelConverter.dir/includes_CXX.rsp -s WASM=1 -s
>> ALLOW_MEMORY_GROWTH=1 -DNDEBUG -O2   -std=gnu++11 -o
>> CMakeFiles/cadModelConverter.dir/main.cpp.o -c
>> /home/adam/projects/EmscriptenProjects/CadModelConverter/main.cpp
>>
>>
>> /home/adam/Temp/emsdk/upstream/emscripten/em++  -DOCC_CONVERT_SIGNALS
>> @CMakeFiles/cadModelConverter.dir/includes_CXX.rsp -s WASM=1 -s
>> ALLOW_MEMORY_GROWTH=1 -DNDEBUG -O2   -std=gnu++11 -o
>> CMakeFiles/cadModelConverter.dir/myvrmlapi_writer.cpp.o -c
>> /home/adam/projects/EmscriptenProjects/CadModelConverter/myvrmlapi_writer.cpp
>>
>>
>> /home/adam/Temp/emsdk/upstream/emscripten/em++   -s WASM=1 -s
>> ALLOW_MEMORY_GROWTH=1 -DNDEBUG -O2  -O2 --bind  -s FORCE_FILESYSTEM=1
>> @CMakeFiles/cadModelConverter.dir/objects1.rsp  -o cadModelConverter.js
>> @CMakeFiles/cadModelConverter.dir/linklibs.rsp
>>
>>
>> Performance is more or less the same.
>>
>> Regards
>>
>> Adam
>>
>>
>>
>>
>> W dniu 26.01.2021 o 22:28, 'Thomas Lively' via emscripten-discuss pisze:
>>
>> Do you see those optimization flags being used in the verbose make
>> output? For example, in the output in your original message, you have
>>
>> /home/adam/Temp/emsdk/upstream/emscripten/em++
>> -I/home/adam/projects/EmscriptenProjects/CadModelConverter
>> -I/home/adam/Temp/instal/OCCT_emsdk/include/opencascade  -s WASM=1 -s
>> ALLOW_MEMORY_GROWTH=1 -v   -std=gnu++11 -o
>> CMakeFiles/cadModelConverter.dir/fileconverter.cpp.o -c
>> /home/adam/projects/EmscriptenProjects/CadModelConverter/fileconverter.cpp
>>
>>
>> Clearly some flags like " -s WASM=1 -s ALLOW_MEMORY_GROWTH=1" are being
>> used, but I would have expected to see optimization flags here as well.
>>
>> On Tue, Jan 26, 2021 at 1:22 PM Adam Wnęk  wrote:
>>
>>> Hi Thomas,
>>>
>>> I'm using -O3 right now.  There was no substantial difference between
>>> this and -O2
>>>
>>> Adam
>>>
>>>
>>> W dniu 26.01.2021 o 18:56, 'Thomas Lively' via emscripten-discuss pisze:
>>>
>>> Hi Adam,
>>>
>>> I don't see any optimization flags used in your Make output. Does
>>> compiling with `-O2` or `-O3` make a difference?
>>>
>>> Thomas
>>>
>>> On Tue, Jan 26, 2021 at 8:17 AM Adam Wnęk  wrote:
>>>
>>>>
>>>> Hi
>>>> I have small application converting files from IGES to VRML format. Im
>>>> using OPENCASCADE librariesto do so. After compilation in emscripten
>>>> application works but it is much slower than the same code complied using
>>>> "normal" compilation.
>>>> Processing one file takes several seconds then while doing the same in
>>>> browser using wasm module takes several minutes.
>>>> In wasm 

Re: Emscripten compilation works really slow on web browsers.

['Thomas Lively' via emscripten-discuss]

Ok, thanks for verifying. I'm not familiar with the libraries you're using.
Do they use SIMD or multithreading in the native versions? That could be a
source of large slowdowns if you're not using those features in the
WebAssembly version. You also might want to profile your application in
Chrome's DevTools to see where it is spending its time and compare that to
a profile of the native build.

On Wed, Jan 27, 2021 at 1:22 PM Adam Wnęk  wrote:

> Hi,
>
> I have checked once again. My previous snapshot  from make output was
> without optimization indeed (different configuration)
>
> Right  one looks like that:
>
> /home/adam/Temp/emsdk/upstream/emscripten/em++  -DOCC_CONVERT_SIGNALS
> @CMakeFiles/cadModelConverter.dir/includes_CXX.rsp -s WASM=1 -s
> ALLOW_MEMORY_GROWTH=1 -DNDEBUG -O2   -std=gnu++11 -o
> CMakeFiles/cadModelConverter.dir/fileconverter.cpp.o -c
> /home/adam/projects/EmscriptenProjects/CadModelConverter/fileconverter.cpp
>
>
> /home/adam/Temp/emsdk/upstream/emscripten/em++  -DOCC_CONVERT_SIGNALS
> @CMakeFiles/cadModelConverter.dir/includes_CXX.rsp -s WASM=1 -s
> ALLOW_MEMORY_GROWTH=1 -DNDEBUG -O2   -std=gnu++11 -o
> CMakeFiles/cadModelConverter.dir/main.cpp.o -c
> /home/adam/projects/EmscriptenProjects/CadModelConverter/main.cpp
>
>
> /home/adam/Temp/emsdk/upstream/emscripten/em++  -DOCC_CONVERT_SIGNALS
> @CMakeFiles/cadModelConverter.dir/includes_CXX.rsp -s WASM=1 -s
> ALLOW_MEMORY_GROWTH=1 -DNDEBUG -O2   -std=gnu++11 -o
> CMakeFiles/cadModelConverter.dir/myvrmlapi_writer.cpp.o -c
> /home/adam/projects/EmscriptenProjects/CadModelConverter/myvrmlapi_writer.cpp
>
>
> /home/adam/Temp/emsdk/upstream/emscripten/em++   -s WASM=1 -s
> ALLOW_MEMORY_GROWTH=1 -DNDEBUG -O2  -O2 --bind  -s FORCE_FILESYSTEM=1
> @CMakeFiles/cadModelConverter.dir/objects1.rsp  -o cadModelConverter.js
> @CMakeFiles/cadModelConverter.dir/linklibs.rsp
>
>
> Performance is more or less the same.
>
> Regards
>
> Adam
>
>
>
>
> W dniu 26.01.2021 o 22:28, 'Thomas Lively' via emscripten-discuss pisze:
>
> Do you see those optimization flags being used in the verbose make output?
> For example, in the output in your original message, you have
>
> /home/adam/Temp/emsdk/upstream/emscripten/em++
> -I/home/adam/projects/EmscriptenProjects/CadModelConverter
> -I/home/adam/Temp/instal/OCCT_emsdk/include/opencascade  -s WASM=1 -s
> ALLOW_MEMORY_GROWTH=1 -v   -std=gnu++11 -o
> CMakeFiles/cadModelConverter.dir/fileconverter.cpp.o -c
> /home/adam/projects/EmscriptenProjects/CadModelConverter/fileconverter.cpp
>
>
> Clearly some flags like " -s WASM=1 -s ALLOW_MEMORY_GROWTH=1" are being
> used, but I would have expected to see optimization flags here as well.
>
> On Tue, Jan 26, 2021 at 1:22 PM Adam Wnęk  wrote:
>
>> Hi Thomas,
>>
>> I'm using -O3 right now.  There was no substantial difference between
>> this and -O2
>>
>> Adam
>>
>>
>> W dniu 26.01.2021 o 18:56, 'Thomas Lively' via emscripten-discuss pisze:
>>
>> Hi Adam,
>>
>> I don't see any optimization flags used in your Make output. Does
>> compiling with `-O2` or `-O3` make a difference?
>>
>> Thomas
>>
>> On Tue, Jan 26, 2021 at 8:17 AM Adam Wnęk  wrote:
>>
>>>
>>> Hi
>>> I have small application converting files from IGES to VRML format. Im
>>> using OPENCASCADE librariesto do so. After compilation in emscripten
>>> application works but it is much slower than the same code complied using
>>> "normal" compilation.
>>> Processing one file takes several seconds then while doing the same in
>>> browser using wasm module takes several minutes.
>>> In wasm module source file is saved in FS system than loaded and
>>> processed. output data is send back to JS by value::typed_memory_view.
>>> OPENCASCADE (static) libraries are compiled with emscripten too.
>>> What may be the cause of such huge performance drop? Im stuck there a
>>> bit.
>>> Build platform :Ubuntu
>>>
>>> This is my make output:
>>>
>>> 
>>> /home/adam/projects/EmscriptenProjects/CadModelConverter/build> make -j4
>>> VERBOSE=1
>>> /usr/bin/cmake
>>> -S/home/adam/projects/EmscriptenProjects/CadModelConverter
>>> -B/home/adam/projects/EmscriptenProjects/CadModelConverter/build
>>> --check-build-system CMakeFiles/Makefile.cmake 0
>>> Re-run cmake file: Makefile older than: ../CMakeLists.txt
>>> -- Using OpenCASCADE from
>>> "/home/adam/Temp/instal/OCCT_emsdk/lib

Re: Emscripten compilation works really slow on web browsers.

['Thomas Lively' via emscripten-discuss]

Do you see those optimization flags being used in the verbose make output?
For example, in the output in your original message, you have

/home/adam/Temp/emsdk/upstream/emscripten/em++
-I/home/adam/projects/EmscriptenProjects/CadModelConverter
-I/home/adam/Temp/instal/OCCT_emsdk/include/opencascade  -s WASM=1 -s
ALLOW_MEMORY_GROWTH=1 -v   -std=gnu++11 -o
CMakeFiles/cadModelConverter.dir/fileconverter.cpp.o -c
/home/adam/projects/EmscriptenProjects/CadModelConverter/fileconverter.cpp


Clearly some flags like " -s WASM=1 -s ALLOW_MEMORY_GROWTH=1" are being
used, but I would have expected to see optimization flags here as well.

On Tue, Jan 26, 2021 at 1:22 PM Adam Wnęk  wrote:

> Hi Thomas,
>
> I'm using -O3 right now.  There was no substantial difference between this
> and -O2
>
> Adam
>
>
> W dniu 26.01.2021 o 18:56, 'Thomas Lively' via emscripten-discuss pisze:
>
> Hi Adam,
>
> I don't see any optimization flags used in your Make output. Does
> compiling with `-O2` or `-O3` make a difference?
>
> Thomas
>
> On Tue, Jan 26, 2021 at 8:17 AM Adam Wnęk  wrote:
>
>>
>> Hi
>> I have small application converting files from IGES to VRML format. Im
>> using OPENCASCADE librariesto do so. After compilation in emscripten
>> application works but it is much slower than the same code complied using
>> "normal" compilation.
>> Processing one file takes several seconds then while doing the same in
>> browser using wasm module takes several minutes.
>> In wasm module source file is saved in FS system than loaded and
>> processed. output data is send back to JS by value::typed_memory_view.
>> OPENCASCADE (static) libraries are compiled with emscripten too.
>> What may be the cause of such huge performance drop? Im stuck there a bit.
>> Build platform :Ubuntu
>>
>> This is my make output:
>>
>> 
>> /home/adam/projects/EmscriptenProjects/CadModelConverter/build> make -j4
>> VERBOSE=1
>> /usr/bin/cmake -S/home/adam/projects/EmscriptenProjects/CadModelConverter
>> -B/home/adam/projects/EmscriptenProjects/CadModelConverter/build
>> --check-build-system CMakeFiles/Makefile.cmake 0
>> Re-run cmake file: Makefile older than: ../CMakeLists.txt
>> -- Using OpenCASCADE from
>> "/home/adam/Temp/instal/OCCT_emsdk/lib/cmake/opencascade/"
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to:
>> /home/adam/projects/EmscriptenProjects/CadModelConverter/build
>> /usr/bin/cmake -E cmake_progress_start
>> /home/adam/projects/EmscriptenProjects/CadModelConverter/build/CMakeFiles
>> /home/adam/projects/EmscriptenProjects/CadModelConverter/build/CMakeFiles/progress.marks
>> /usr/bin/make -f CMakeFiles/Makefile2 all
>> make[1]: Entering directory
>> '/home/adam/projects/EmscriptenProjects/CadModelConverter/build'
>> /usr/bin/make -f CMakeFiles/cadModelConverter.dir/build.make
>> CMakeFiles/cadModelConverter.dir/depend
>> make[2]: Entering directory
>> '/home/adam/projects/EmscriptenProjects/CadModelConverter/build'
>> cd /home/adam/projects/EmscriptenProjects/CadModelConverter/build &&
>> /usr/bin/cmake -E cmake_depends "Unix Makefiles"
>> /home/adam/projects/EmscriptenProjects/CadModelConverter
>> /home/adam/projects/EmscriptenProjects/CadModelConverter
>> /home/adam/projects/EmscriptenProjects/CadModelConverter/build
>> /home/adam/projects/EmscriptenProjects/CadModelConverter/build
>> /home/adam/projects/EmscriptenProjects/CadModelConverter/build/CMakeFiles/cadModelConverter.dir/DependInfo.cmake
>> --color=
>> Dependee
>> "/home/adam/projects/EmscriptenProjects/CadModelConverter/build/CMakeFiles/cadModelConverter.dir/DependInfo.cmake"
>> is newer than depender
>> "/home/adam/projects/EmscriptenProjects/CadModelConverter/build/CMakeFiles/cadModelConverter.dir/depend.internal".
>> Scanning dependencies of target cadModelConverter
>> make[2]: Leaving directory
>> '/home/adam/projects/EmscriptenProjects/CadModelConverter/build'
>> /usr/bin/make -f CMakeFiles/cadModelConverter.dir/build.make
>> CMakeFiles/cadModelConverter.dir/build
>> make[2]: Entering directory
>> '/home/adam/projects/EmscriptenProjects/CadModelConverter/build'
>> [ 20%] Building CXX object
>> CMakeFiles/cadModelConverter.dir/fileconverter.cpp.o
>> /home/adam/Temp/emsdk/upstream/emscripten/em++
>> -I/home/adam/projects/EmscriptenProjects/CadModelConverter
>> -I/home/adam/Temp/instal/OCCT_emsdk/include/opencascade  -s WASM=1 -s
>> ALLOW_ME

Re: Emscripten compilation works really slow on web browsers.

['Thomas Lively' via emscripten-discuss]

Hi Adam,

I don't see any optimization flags used in your Make output. Does compiling
with `-O2` or `-O3` make a difference?

Thomas

On Tue, Jan 26, 2021 at 8:17 AM Adam Wnęk  wrote:

>
> Hi
> I have small application converting files from IGES to VRML format. Im
> using OPENCASCADE librariesto do so. After compilation in emscripten
> application works but it is much slower than the same code complied using
> "normal" compilation.
> Processing one file takes several seconds then while doing the same in
> browser using wasm module takes several minutes.
> In wasm module source file is saved in FS system than loaded and
> processed. output data is send back to JS by value::typed_memory_view.
> OPENCASCADE (static) libraries are compiled with emscripten too.
> What may be the cause of such huge performance drop? Im stuck there a bit.
> Build platform :Ubuntu
>
> This is my make output:
>
> 
> /home/adam/projects/EmscriptenProjects/CadModelConverter/build> make -j4
> VERBOSE=1
> /usr/bin/cmake -S/home/adam/projects/EmscriptenProjects/CadModelConverter
> -B/home/adam/projects/EmscriptenProjects/CadModelConverter/build
> --check-build-system CMakeFiles/Makefile.cmake 0
> Re-run cmake file: Makefile older than: ../CMakeLists.txt
> -- Using OpenCASCADE from
> "/home/adam/Temp/instal/OCCT_emsdk/lib/cmake/opencascade/"
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
> /home/adam/projects/EmscriptenProjects/CadModelConverter/build
> /usr/bin/cmake -E cmake_progress_start
> /home/adam/projects/EmscriptenProjects/CadModelConverter/build/CMakeFiles
> /home/adam/projects/EmscriptenProjects/CadModelConverter/build/CMakeFiles/progress.marks
> /usr/bin/make -f CMakeFiles/Makefile2 all
> make[1]: Entering directory
> '/home/adam/projects/EmscriptenProjects/CadModelConverter/build'
> /usr/bin/make -f CMakeFiles/cadModelConverter.dir/build.make
> CMakeFiles/cadModelConverter.dir/depend
> make[2]: Entering directory
> '/home/adam/projects/EmscriptenProjects/CadModelConverter/build'
> cd /home/adam/projects/EmscriptenProjects/CadModelConverter/build &&
> /usr/bin/cmake -E cmake_depends "Unix Makefiles"
> /home/adam/projects/EmscriptenProjects/CadModelConverter
> /home/adam/projects/EmscriptenProjects/CadModelConverter
> /home/adam/projects/EmscriptenProjects/CadModelConverter/build
> /home/adam/projects/EmscriptenProjects/CadModelConverter/build
> /home/adam/projects/EmscriptenProjects/CadModelConverter/build/CMakeFiles/cadModelConverter.dir/DependInfo.cmake
> --color=
> Dependee
> "/home/adam/projects/EmscriptenProjects/CadModelConverter/build/CMakeFiles/cadModelConverter.dir/DependInfo.cmake"
> is newer than depender
> "/home/adam/projects/EmscriptenProjects/CadModelConverter/build/CMakeFiles/cadModelConverter.dir/depend.internal".
> Scanning dependencies of target cadModelConverter
> make[2]: Leaving directory
> '/home/adam/projects/EmscriptenProjects/CadModelConverter/build'
> /usr/bin/make -f CMakeFiles/cadModelConverter.dir/build.make
> CMakeFiles/cadModelConverter.dir/build
> make[2]: Entering directory
> '/home/adam/projects/EmscriptenProjects/CadModelConverter/build'
> [ 20%] Building CXX object
> CMakeFiles/cadModelConverter.dir/fileconverter.cpp.o
> /home/adam/Temp/emsdk/upstream/emscripten/em++
> -I/home/adam/projects/EmscriptenProjects/CadModelConverter
> -I/home/adam/Temp/instal/OCCT_emsdk/include/opencascade  -s WASM=1 -s
> ALLOW_MEMORY_GROWTH=1 -v   -std=gnu++11 -o
> CMakeFiles/cadModelConverter.dir/fileconverter.cpp.o -c
> /home/adam/projects/EmscriptenProjects/CadModelConverter/fileconverter.cpp
> [ 40%] Building CXX object CMakeFiles/cadModelConverter.dir/main.cpp.o
> /home/adam/Temp/emsdk/upstream/emscripten/em++
> -I/home/adam/projects/EmscriptenProjects/CadModelConverter
> -I/home/adam/Temp/instal/OCCT_emsdk/include/opencascade  -s WASM=1 -s
> ALLOW_MEMORY_GROWTH=1 -v   -std=gnu++11 -o
> CMakeFiles/cadModelConverter.dir/main.cpp.o -c
> /home/adam/projects/EmscriptenProjects/CadModelConverter/main.cpp
> [ 60%] Building CXX object
> CMakeFiles/cadModelConverter.dir/myvrmlapi_writer.cpp.o
> /home/adam/Temp/emsdk/upstream/emscripten/em++
> -I/home/adam/projects/EmscriptenProjects/CadModelConverter
> -I/home/adam/Temp/instal/OCCT_emsdk/include/opencascade  -s WASM=1 -s
> ALLOW_MEMORY_GROWTH=1 -v   -std=gnu++11 -o
> CMakeFiles/cadModelConverter.dir/myvrmlapi_writer.cpp.o -c
> /home/adam/projects/EmscriptenProjects/CadModelConverter/myvrmlapi_writer.cpp
> shared:INFO: (Emscripten: Running sanity checks)
> shared:INFO: (Emscripten: Running sanity checks)
> shared:INFO: (Emscripten: Running sanity checks)
>  "/home/adam/Temp/emsdk/upstream/bin/clang++" -DEMSCRIPTEN
> -fignore-exceptions -mllvm -combiner-global-alias-analysis=false -mllvm
> -enable-emscripten-sjlj -mllvm -disable-lsr -Xclang
> -isystem/home/adam/Temp/emsdk/upstream/emscripten/system/include/SDL
> -target 

Re: Dealing with "Maximum call stack size exceeded" on fsanitize=undefined

['Thomas Lively' via emscripten-discuss]

Thanks, I am able to reproduce the issue locally. Looking into it now.

On Thu, Jan 21, 2021 at 7:15 PM 'Maksim Ivanov' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> The minimized repro is:
>
> #include 
> #include 
> class A final {
>  public:
>   MOCK_METHOD0(Foo, void());
> };
> TEST(Some, DISABLED_Basic) {
>   A a;
>   EXPECT_CALL(a, Foo());
> }
>
> Googletest/mock are 1.10.0.
>
>
> Maksim
>
>
> On Fri, Jan 22, 2021 at 1:07 AM Maksim Ivanov  wrote:
>
>> Thanks, Alon.
>> I added this flag and, indeed, it's an infinite recursion.
>>
>> I'll update this thread once I have a minimized repro sample to share.
>>
>>
>> Maksim
>>
>>
>> On Fri, Jan 22, 2021 at 12:06 AM Alon Zakai  wrote:
>>
>>> Different versions of node may truncate the stack to different defaults.
>>> But it is configurable, try
>>>
>>> node --stack-trace-limit=1000
>>>
>>> On Thu, Jan 21, 2021 at 2:53 PM 'Maksim Ivanov' via emscripten-discuss <
>>> emscripten-discuss@googlegroups.com> wrote:
>>>
>>>> @Alon: Hard to say whether it's an infinite recursion - the snippet I
>>>> attached is all what's output. Can it be that something truncates the stack
>>>> before printing, without leaving any trace of what was truncated?
>>>> My other hypothesis was that some code generated by UBSan allocates
>>>> huge variables on stack; again, I don't know how to verify that.
>>>>
>>>> @Thomas: Sure; I'll probably be able to do it in a couple of days,
>>>> after minimizing the repro and removing irrelevant details from it.
>>>>
>>>>
>>>> Maksim
>>>>
>>>>
>>>> On Thu, Jan 21, 2021 at 11:49 PM 'Thomas Lively' via emscripten-discuss
>>>>  wrote:
>>>>
>>>>> I've seen reports of infinite recursions involving
>>>>> __ubsan_handle_dynamic_type_cache_miss before, but I've never been able to
>>>>> reproduce them to investigate. Would you be able to share your reproducer?
>>>>>
>>>>> On Thu, Jan 21, 2021 at 2:24 PM Alon Zakai 
>>>>> wrote:
>>>>>
>>>>>> Does the stack trace look like it's an infinite recursion? That could
>>>>>> be a toolchain bug.
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 20, 2021 at 11:58 AM 'Maksim Ivanov' via
>>>>>> emscripten-discuss  wrote:
>>>>>>
>>>>>>> Hello, does anyone have a tip on how to work around the "Maximum
>>>>>>> call stack size exceeded" error when running a UBsan-sanitized 
>>>>>>> Emscripten
>>>>>>> program under Node?
>>>>>>>
>>>>>>> The error is:
>>>>>>>
>>>>>>> "RangeError: Maximum call stack size exceeded
>>>>>>> at _emscripten_return_address (a.out.js:6788:35)
>>>>>>> at __ubsan_handle_dynamic_type_cache_miss
>>>>>>> (wasm-function[8220]:0x210eb3)
>>>>>>> at std::type_info::operator==(std::type_info const&) const
>>>>>>> (wasm-function[938]:0x648b3)
>>>>>>> at is_equal(std::type_info const*, std::type_info const*, bool)
>>>>>>> (wasm-function[8154]:0x20a911)
>>>>>>> at __dynamic_cast (wasm-function[8156]:0x20aa48)
>>>>>>> at __ubsan::checkDynamicType(void*, void*, unsigned long)
>>>>>>> (wasm-function[8196]:0x20f1b9)
>>>>>>> at
>>>>>>> HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned
>>>>>>> long, unsigned long, __ubsan::ReportOptions) 
>>>>>>> (wasm-function[8221]:0x210f03)
>>>>>>> at __ubsan_handle_dynamic_type_cache_miss
>>>>>>> (wasm-function[8220]:0x210ed7)
>>>>>>> at std::type_info::operator==(std::type_info const&) const
>>>>>>> (wasm-function[938]:0x648b3)
>>>>>>> at is_equal(std::type_info const*, std::type_info const*, bool)
>>>>>>> (wasm-function[8154]:0x20a911)"
>>>>>>>
>>>>>>> I'm not 100% sure, but it seems that the error doesn't indicate a
>>>>>>> bug in the program, because it doesn't appear when compiling a small
>

Re: Support for externref

['Thomas Lively' via emscripten-discuss]

I don't think so, but you can keep an eye on commits from "wingo" and
"pmatos" on reviews.llvm.org to keep track of the progress.

On Mon, Jan 25, 2021 at 12:55 AM ben layet  wrote:

> Thanks!
> Is there a feature ticket in a publicly visible ticket tracker that I can
> keep an eye on?
> cheers
> ben
>
> On Saturday, 23 January 2021 at 17:54:25 UTC tli...@google.com wrote:
>
>> Not yet, but there are some folks working on this. Perhaps it will be
>> ready to use in a few months? It’s hard to say for sure.
>>
>> On Sat, Jan 23, 2021 at 03:49 ben layet  wrote:
>>
>>> Does emscripten support externref reference types for holding opaque
>>> handles to JS objects in C++? If not, any idea when?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-disc...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/7f6178fa-bd05-4f65-aa7c-9e5a405bf851n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/68c9b121-f12f-44fa-a91c-2a8b73d2f456n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EUPn6i0nytqgmxwNKu80kUO_1NgEnJLVc1DeGuXjpO5UA%40mail.gmail.com.

Re: Support for externref

['Thomas Lively' via emscripten-discuss]

Not yet, but there are some folks working on this. Perhaps it will be ready
to use in a few months? It’s hard to say for sure.

On Sat, Jan 23, 2021 at 03:49 ben layet  wrote:

> Does emscripten support externref reference types for holding opaque
> handles to JS objects in C++? If not, any idea when?
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/7f6178fa-bd05-4f65-aa7c-9e5a405bf851n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EW4L8xuF%2BEedzVZGmvTj7qqt00BKFrKNKMf-ATSXwSSOw%40mail.gmail.com.

Re: Dealing with "Maximum call stack size exceeded" on fsanitize=undefined

['Thomas Lively' via emscripten-discuss]

I've seen reports of infinite recursions involving
__ubsan_handle_dynamic_type_cache_miss before, but I've never been able to
reproduce them to investigate. Would you be able to share your reproducer?

On Thu, Jan 21, 2021 at 2:24 PM Alon Zakai  wrote:

> Does the stack trace look like it's an infinite recursion? That could be a
> toolchain bug.
>
>
> On Wed, Jan 20, 2021 at 11:58 AM 'Maksim Ivanov' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> Hello, does anyone have a tip on how to work around the "Maximum call
>> stack size exceeded" error when running a UBsan-sanitized Emscripten
>> program under Node?
>>
>> The error is:
>>
>> "RangeError: Maximum call stack size exceeded
>> at _emscripten_return_address (a.out.js:6788:35)
>> at __ubsan_handle_dynamic_type_cache_miss
>> (wasm-function[8220]:0x210eb3)
>> at std::type_info::operator==(std::type_info const&) const
>> (wasm-function[938]:0x648b3)
>> at is_equal(std::type_info const*, std::type_info const*, bool)
>> (wasm-function[8154]:0x20a911)
>> at __dynamic_cast (wasm-function[8156]:0x20aa48)
>> at __ubsan::checkDynamicType(void*, void*, unsigned long)
>> (wasm-function[8196]:0x20f1b9)
>> at HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*,
>> unsigned long, unsigned long, __ubsan::ReportOptions)
>> (wasm-function[8221]:0x210f03)
>> at __ubsan_handle_dynamic_type_cache_miss
>> (wasm-function[8220]:0x210ed7)
>> at std::type_info::operator==(std::type_info const&) const
>> (wasm-function[938]:0x648b3)
>> at is_equal(std::type_info const*, std::type_info const*, bool)
>> (wasm-function[8154]:0x20a911)"
>>
>> I'm not 100% sure, but it seems that the error doesn't indicate a bug in
>> the program, because it doesn't appear when compiling a small program
>> (e.g., a Googletest binary with 0 tests) and begins to appear even after
>> adding unused code (e.g., a bunch of disabled Googletest tests).
>>
>> I tried passing "--stack_size=8192" to Node, but this didn't help; also,
>> when increasing the number (e.g., to 131072) I'm starting to get a
>> different error:
>>
>> RuntimeError: memory access out of bounds
>> at __dynamic_cast (wasm-function[8156]:0x20aa0f)
>> at __ubsan::checkDynamicType(void*, void*, unsigned long)
>> (wasm-function[8196]:0x20f1b9)
>> at HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*,
>> unsigned long, unsigned long, __ubsan::ReportOptions)
>> (wasm-function[8221]:0x210f03)
>> at __ubsan_handle_dynamic_type_cache_miss
>> (wasm-function[8220]:0x210ed7)
>> at std::type_info::operator==(std::type_info const&) const
>> (wasm-function[938]:0x648b3)
>> at is_equal(std::type_info const*, std::type_info const*, bool)
>> (wasm-function[8154]:0x20a911)
>> at __dynamic_cast (wasm-function[8156]:0x20aa48)
>> at __ubsan::checkDynamicType(void*, void*, unsigned long)
>> (wasm-function[8196]:0x20f1b9)
>> at HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*,
>> unsigned long, unsigned long, __ubsan::ReportOptions)
>> (wasm-function[8221]:0x210f03)
>> at __ubsan_handle_dynamic_type_cache_miss
>> (wasm-function[8220]:0x210ed7)
>>
>> Thanks.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/8c9c6b8b-a4b1-427c-965c-5828f8fa8fe9n%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRAZ87AKvva7HxffLjQa64rGHk%3Dp%3DxfiWjgRO6X0iZzVg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EWHYYeb6q8TU690PR%2Bk%3DtpBPAEU%2Bp6fp_Xvi%3DDiaHWKyg%40mail.gmail.com.

Re: C compilation bug

['Thomas Lively' via emscripten-discuss]

Does the problem reproduce on a newer Emscripten? It sounds like either a
bug in LLVM (which would probably have been fixed by now) or perhaps
undefined behavior in your program. If you can reproduce the issue with the
latest Emscripten, would you be able to provide source code that
demonstrates the problem?

On Tue, Nov 10, 2020 at 3:12 PM juergen...@gmail.com <
juergen.wot...@gmail.com> wrote:

> I just refactored some old C code of mine. Surprisingly the updated code
> failed in a very unexpected manner that I still don't understand. I
> narrowed the problem down and here is what the relevant code looks like:
>
> static uint8_t _x, _y; // ... _x and _y get both initialized and updated
> elsewhere
> void setOutput(uint8_t val) { ...}void someFunction() {
>static uint8_t tmp;
>...
>swich(..) {
>   case foo: {
>  // tmp = _x & _y;
>  setOutput( _x & _y);
>   }
>   ...
>}
> }
>
> The code fails because the _x & _y expression suddenly passes total
> garbage
> to the setOutput() function. Originally I had used the commented tmp
> assignment
> and then used tmp as an argument for that call - and that functions
> correctly.
>
> However what I find most puzzling is this: simply uncommenting the "tmp"
> assignment - without even using tmp later) makes the problem
> disappear...WTF?!
>
> I am still using an older Emscripten  version 1.38 and the effect is there
> regardless if I compile to WASM or asm.js and whether or not I am using
> different optimizer options or the closure compiler.
>
> Any ideas what is going on here? Is this some kind of known bug or some C
> feature that I am not aware of..
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/636d73be-ce53-4a55-bdba-66b7ab938887n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EViavdYo5K2J7ZXg%3DDjo1b0aiboaj7nr8H%3DkB8sSoiQAw%40mail.gmail.com.

Re: Compiling to LLVM IR

['Thomas Lively' via emscripten-discuss]

What version of LLVM does Smack support? Since Emscripten uses tip-of-tree
LLVM, my guess is that the LLVM IR you're getting is too new for Smack to
read. It's hard to say from just that error message, though.

On Tue, Nov 3, 2020 at 4:36 PM Yugesh Kothari 
wrote:

> Hi,
>
> I am trying to look for a way to compile C/C++ source written with
> emsripten headers to LLVM IR (.ll or .bc) and then subsequently use smack (
> https://github.com/smackers/smack) to get it to boogie. I use the command
> :
>
> emsdk/upstream/bin/clang++ --target=wasm64 `em++ --cflags` -emit-llvm -S
> .cpp -o .ll
>
> which runs. But then when I try to use smack I get this error:
> "Exception: Problem reading input bitcode/IR: Invalid record".
>
> I run into the same problem if I try to compile down the above llvm to an
> executable using llc.
>
> I suspect this has something to do with how I originally compiled my C++
> source. Can someone suggest what is the "right" way to get LLVM IR and
> .js+.wasm instead of just the latter?
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/003bfb97-7658-4291-93b0-46f8ec3cd03cn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EW%2BypLAJ7T23TB_gbNaZQUFJ34hS2hBH-3%2BRDdFJhLOaQ%40mail.gmail.com.

Re: Help required for wasm-emscripten-finalize

['Thomas Lively' via emscripten-discuss]

Yes, please file an issue for this. If you could set EMCC_DEBUG=1 and
include the debug logs in the bug report, that would be very helpful. It
would also be helpful if you could supply the exact version of LLVM you are
trying to compile.

On Thu, Oct 15, 2020 at 01:09 vivek pandya  wrote:

>
> Hi,
>
> I am compiling llvm opt tool through emscirpten to WASM,
>
> My commands are
>  emcmake cmake ../llvm-project/llvm/
> emmake make opt
>
> and I am encountering following error:
> do you have any idea if you have faced similar issue?
>
> em++: error: '/home/vivek/emsdk/upstream/bin/wasm-emscripten-finalize
> --detect-features --minimize-wasm-changes -g --dyncalls-i64
> --global-base=1024 --dwarf /tmp/emscripten_temp/llvm-tblgen.wasm -o
> /tmp/emscripten_temp/llvm-tblgen.wasm' failed (-9)
>
>
> Should I file github issue for this?
>
> Thanks,
> Vivek
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/441ab06e-5d70-4d77-8804-f1607003aa36n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EVyqobfwwmvXiXGAz9bDYPx2mGj%3DGx3kC-pOX_N-L4cYg%40mail.gmail.com.

Re: cannot post to group

['Thomas Lively' via emscripten-discuss]

FWIW, this post got through fine. I'm not sure what could be blocking other
posts.

On Thu, Sep 3, 2020 at 12:10 PM r0ller  wrote:

> Hi,
>
> I hope someone who can help reads this. It seems that I cannot post any
> more in the group and cannot reply to anyone. It may be a spamfilter stuff
> but anyhow, could anyone help me with this?
>
> Thanks in advance,
> r0ller
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/Ay1P5g.atVBG8w1thtW.pDV67TUUKN5zFocVb%40freemail.hu
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EWzQTeV-r9dJ85yFEsU3nA8KJRtH%2BzG66b55GSGeyGHOQ%40mail.gmail.com.

Re: 2.0.0!

['Thomas Lively' via emscripten-discuss]

Emsdk is the official way to install new versions of emscripten, so you're
not losing out on anything by using it :) Installing all the different
parts of Emscripten without using emsdk is actually a huge pain and doesn't
have any benefits unless you're doing development on Emscripten itself.

On Wed, Aug 19, 2020 at 4:45 PM Lailton Fernando Mariano <
lailton.s...@gmail.com> wrote:

> Thanks for reply,
> And are there a tutorial how to compile it using hard mode ( emscripten )
> and not using the easy mode ( emsdk ) ?
>
> Because if I use a prebuild it mean that it is outdated and all new
> updates are not available right?
>
> Thanks
>
> Em quarta-feira, 19 de agosto de 2020 às 20:22:10 UTC-3, s...@google.com
> escreveu:
>
>> On Wed, Aug 19, 2020 at 4:13 PM Lailton Fernando Mariano <
>> lailto...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Sorry for my stupid question but someone can explain me what is the
>>> difference about:
>>> https://github.com/emscripten-core/emscripten and
>>> https://github.com/emscripten-core/emsdk ?
>>>
>>
>> emscripten is the compiler itself (really a compiler driver) and it has
>> many dependencies such as llvm, nodejs, python, and binaryen.
>>
>> emsdk is an easy way to install emscripten along with pre-built and
>> tested versions of all its dependencies.
>>
>>
>>> I normally use the emsdk to compile my C codes to create the WASM and
>>> run into web.
>>>
>>> Thanks
>>> Em quarta-feira, 19 de agosto de 2020 às 12:25:41 UTC-3,
>>> alon...@gmail.com escreveu:
>>>
 Hi everyone,

 Last week we released Emscripten 2.0.0. That's a big milestone as it's
 the first version to not support the old fastcomp backend anymore,

 https://github.com/emscripten-core/emscripten/issues/11319

 You can still use it by using an older version (the last to support
 fastcomp is 1.40.1), but the new upstream backend is better in every way!
 And it's been the default version when you install "latest" etc. for quite
 a while now.

 This is also the first version to not support Python 2.*, and only
 support 3.*

 Both of those don't have immediate benefits, but they are letting us do
 a lot of cleanups and simplifications. See

 https://github.com/emscripten-core/emscripten/issues/11860

 We've already improved code quality quite a bit in just a week, and
 there's a lot more to come. These simplifications will speed up
 development. They will also unblock some things that were tricky to do
 while we supported two backends, such as some link time improvements and
 better debugging support - specifically we aim to do less during -O0 links,
 both for speed and to properly preserve DWARF info (for example, one of the
 first parts of that is in
 https://github.com/WebAssembly/binaryen/pull/3044).

 - Alon

 --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-disc...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/036646c8-e19b-41bc-8c0c-f27ed2b02918n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/08596540-9012-4c5a-975c-a37ad5fc240dn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EVM%3D2Cf5aZSUy4bHXzMEE61vzPW7n5uTfmM6snnVJ-DNw%40mail.gmail.com.

Re: Current EMSDK Node version out of date?

['Thomas Lively' via emscripten-discuss]

FWIW I usually run SIMD tests using V8's debugging shell d8. You can get
nightly builds of it easily from JSVU (
https://github.com/GoogleChromeLabs/jsvu). It doesn't have all the Node
APIs, so it may not suit your needs for end-to-end testing of full
applications, but I've found it useful for testing SIMD codegen. Node
nightly does not have a recent enough version of V8 to work yet, but there
is an experimental version of node that automatically pulls in the most
recent V8 at https://github.com/nodejs/node-v8. I've never used it, but
it's worth a shot if d8 is too limited for you.


On Fri, Jul 10, 2020 at 5:31 PM 'Steven Johnson' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> AFAICT, the current EMSDK (1.39.19) uses the finalized opcodes for the
> simd128 feature set, but the version of Node that is included in the
> EMSDK does not. This makes for amusing runtime errors if you try to
> compile wasm and test via Node.
>
> - If this is in fact the case (and not a stupid config error on my
> part), may I suggest that the EMSDK release notes point this out?
> (Maybe most folks aren't relying on Node for wasm-testing purposes,
> but it's handy and seems like it would be in sync, since it's
> included...)
>
> - Is there any ETA for when a stable version of Node with final
> wasm-simd support will be available?
>
> - If there is no ETA, are there other fast (non-browser) command-line
> wasm implementations that would be suitable for testing (ie up to date
> with the final spec)? (WABT's wasm-interp tool would be great but is
> too slow for some of my purposes)
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAM%3Ddnvc9HJtUQ69mb_RNXKRxq9Quz8tfQy6v7s04oMvpLu2Efw%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXsdbmsW1v4z4fJo5NEOnkVg3yYsvsCZFhiSqXFAYuH6w%40mail.gmail.com.

Re: Thoughts on future ARM64 support for emsdk?

['Thomas Lively' via emscripten-discuss]

How does the wasm2c build work with something as large as LLVM? I would
assume that at some point the C file would get so large that the C compiler
would fall over.

On Thu, Jul 9, 2020 at 12:58 PM Alon Zakai  wrote:

> At the risk of sounding like a broken record - I've been talking about the
> next idea a lot recently ;) - I think this is something wasm2c can help
> with. I just gave a talk about how:
>
> http://kripken.github.io/talks/2020/universal.html#/
>
> The idea is that we add a single additional build target, "universal C",
> which compiles LLVM and Binaryen to portable C code that can then be
> compiled on practically any platform. So this new "build" would be C, and
> people would download those C files and run a simple command to build them
> locally. After the local build you end up with a normal executable that
> just works.
>
> There is still that build step locally, but it's the simplest build
> possible - no build system is needed, no special local setup, no cmake or
> configure, just run gcc or clang on a self-contained C file. That should be
> trivial on ARM64 MacOS or Linux as I believe they have a system C compiler
> installed by default.
>
> I'm not opposed to adding "proper" ARM64 builds, though - ARM64 builds
> would have some benefits over wasm2c. But wasm2c builds do cover the long
> tail of less-common platforms, and we can probably set them up much quicker
> too. I hope to do this for Binaryen soon anyhow.
>
> - Alon
>
> On Thu, Jul 9, 2020 at 11:30 AM Brion Vibber  wrote:
>
>> I've been a bit of an ARM64 enthusiast of late, trying out Linux, Windows
>> 10, and iOS devices that run on the ARM64/Aarch64 family of processors.
>> Emscripten works fine on these machines if one cares to do some light
>> development work on them, but since there's no binaries built from CI, the
>> standard emsdk can only install by building from source -- which can take
>> hours on a middleweight portable machine.
>>
>> Now that Apple is switching their Mac product line to ARM64 processors
>> over the next two years, it will likely become much more common next year
>> for people to have ARM64-based laptop and desktop computers, and some of
>> them will need to build something with emscripten in their workflows either
>> on macOS or on a virtualized Linux in Docker etc.
>>
>> From what I've seen presented at WWDC, the ARM64 Macs will support
>> emulated processes, so it may work to ship the x86_64 binaries with the
>> caveat that they will run much slower than native builds.
>>
>> Virtualized Linux builds would also need native ARM64 binaries to run, or
>> else they'd have to sit there for a couple hours compiling after every
>> upgrade.
>>
>> And of course there are already Windows 10 and Linux computers available
>> with ARM64 processes, on sale since a couple years ago and used in the wild
>> in modest numbers.
>>
>> I get the impression that the biggest roadblock to explicit ARM64 support
>> in emscripten is getting it into the CI infrastructure:
>> * Linux/ARM64 builds and testing?
>> * macOS/ARM64 builds and testing?
>> * Windows/ARM64 builds and testing?
>>
>> It's too soon to start on macOS since it's in beta, dev kits aren't
>> shipped yet, and there's no obvious way yet to figure out how to run tests
>> on a macOS ARM system in CI. :)
>>
>> And I'm less sure how important Win/ARM64 is, given you can use the
>> Linux/ARM64 version in WSL virtualization. But some folks prefer to develop
>> on native Windows, too.
>>
>> If there's any way we can start talking about Linux/ARM64 builds and
>> testing, I would be very happy about it! I would even kick in a few bucks
>> for a VM or something if that would help any. ;)
>>
>> Thanks for your time and your consideration!
>>
>> -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
>> Wikimedia Foundation
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAFnWYT%3D3OLskq1KBtVrgKsq1PTS7eHDxyzpcBpmE8_Bfk7m6Kw%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQoi1LZiw2dPjeMMy2zSf-Z8WFWjpP8K1C-gEx67O5jwg%40mail.gmail.com
> 

Re: Thoughts on future ARM64 support for emsdk?

['Thomas Lively' via emscripten-discuss]

Oh wow it didn't even cross my mind that we would be affected by Apple
switching to ARM. I assume ARM MacOS is something we will want to support
natively at some point, but I don't know whether or not the best solution
is to just wait for our CI providers to add support. You're also right that
ideally we would support ARM64 on all three OSes, but that would double our
testing burden even if all our CI providers supported that. I'm not sure
what the best path forward is.

On Thu, Jul 9, 2020 at 11:30 AM Brion Vibber  wrote:

> I've been a bit of an ARM64 enthusiast of late, trying out Linux, Windows
> 10, and iOS devices that run on the ARM64/Aarch64 family of processors.
> Emscripten works fine on these machines if one cares to do some light
> development work on them, but since there's no binaries built from CI, the
> standard emsdk can only install by building from source -- which can take
> hours on a middleweight portable machine.
>
> Now that Apple is switching their Mac product line to ARM64 processors
> over the next two years, it will likely become much more common next year
> for people to have ARM64-based laptop and desktop computers, and some of
> them will need to build something with emscripten in their workflows either
> on macOS or on a virtualized Linux in Docker etc.
>
> From what I've seen presented at WWDC, the ARM64 Macs will support
> emulated processes, so it may work to ship the x86_64 binaries with the
> caveat that they will run much slower than native builds.
>
> Virtualized Linux builds would also need native ARM64 binaries to run, or
> else they'd have to sit there for a couple hours compiling after every
> upgrade.
>
> And of course there are already Windows 10 and Linux computers available
> with ARM64 processes, on sale since a couple years ago and used in the wild
> in modest numbers.
>
> I get the impression that the biggest roadblock to explicit ARM64 support
> in emscripten is getting it into the CI infrastructure:
> * Linux/ARM64 builds and testing?
> * macOS/ARM64 builds and testing?
> * Windows/ARM64 builds and testing?
>
> It's too soon to start on macOS since it's in beta, dev kits aren't
> shipped yet, and there's no obvious way yet to figure out how to run tests
> on a macOS ARM system in CI. :)
>
> And I'm less sure how important Win/ARM64 is, given you can use the
> Linux/ARM64 version in WSL virtualization. But some folks prefer to develop
> on native Windows, too.
>
> If there's any way we can start talking about Linux/ARM64 builds and
> testing, I would be very happy about it! I would even kick in a few bucks
> for a VM or something if that would help any. ;)
>
> Thanks for your time and your consideration!
>
> -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
> Wikimedia Foundation
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAFnWYT%3D3OLskq1KBtVrgKsq1PTS7eHDxyzpcBpmE8_Bfk7m6Kw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EVv%3DLHPDF4nZeOUX7ryEEAWvAPWRMPKwxX%3DbUh3JTFdnQ%40mail.gmail.com.

Re: Mixing emcc and 'host' toolchains in CMake?

['Thomas Lively' via emscripten-discuss]

I don't have a solution, but if anyone else does I would also be very
interested in hearing about it. Right now we have to separate
Binaryen's native and Emscripten builds and it would be very convenient if
we could do both at once.

On Wed, Jul 8, 2020 at 10:32 AM 'Steven Johnson' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> (This question is more CMake-related than Emscripten-related, but I
> suspect someone else on this list may have encountered it, so thought I'd
> ask here...)
>
> TL;DR: Has anyone attempted to use both the Emscripten toolchain and the
> 'host' toolchain (eg gcc, clang) in the same CMake project?
>
> Some of the tooling in this project (e.g. our crosscompiler tool that
> produces .wasm) really needs to be compiled natively, while other parts
> (e.g. the test suite) needs to be compiled via Emscripten. IIUC, CMake has
> a pretty hard distinction of "one toolchain per language per project,
> period" (unlike, say, Blaze/Bazel, which makes this distinction easy).
>
> There are various ways to work around this (CMake's ExternalProject,
> splitting our project into multiple CMake projects, etc) but they all have
> nontrivial drawbacks, so I thought I'd check to see if anyone has found an
> approach that is simpler to implement and maintain.
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAM%3Ddnvec5z_n7w5THU1%2B0%2BZ5DJ984b9AdPdWN_3HQ6NJx7kYTg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXbjsgTCCT-yB%3D%3DeBT-6FHG1Q325L1bGZ4880o0vPBo9A%40mail.gmail.com.

Re: Does WASM use some sort of RTL compression for the data segment?

['Thomas Lively' via emscripten-discuss]

WebAssembly itself doesn't have any compression in its data segments, but
Binaryen does split up data segments around ranges of zeroes as an
optimization. That transformation depends on the memory being initialized
to zero when it is created, making zeroes in data sections redundant.

On Sat, Jun 20, 2020 at 1:42 PM Floh  wrote:

> I just noticed something interesting... through a stupid mistake on my
> part I accidentally added 4 MBytes of bloat to my native-compiled
> executables, because I statically initialized some innocent looking members
> of a very big global struct variable (so that this global struct only had a
> handful items initialized to non-zero values, but the remaining 4 MBytes
> were all zeros).
>
> Interestingly, the (uncompressed) WASM version *wasn't* 4 MByte, instead
> it was about the same size as if that massive global variable would be in
> the BSS segment (that's why I didn't notice the bloat in the native
> executables, I always check the size of the WASM output very carefully, but
> not for the native builds).
>
> So my question: Does WASM have some sort of simple compression for the
> data segment which kicks in for large chunks of zeroes? I tried to search
> the available WASM info, but couldn't find anything "obvious"...
>
> Thanks!
> -Floh.
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/756dcbba-a40f-4f78-af79-74aa46df7625o%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EUjmu0sm0cyUTXG-FBt5bdXMVPUioru%2B3SMa_uY8zEK%2BQ%40mail.gmail.com.

Re: failed to call xz, please confirm that xz is installed in your system

['Thomas Lively' via emscripten-discuss]

WebAssembly in the browser has no notion of processes (or shells), so
`system` will not work. Whether you compile xz to wasm or use the npm
package, you will probably still have to modify the original code to call
out to some JS that invokes xz rather than using `system`.

On Fri, Jun 12, 2020 at 7:48 AM Fernando Bitti Loureiro <
fernando.bi...@gmail.com> wrote:

>
> Let me resort again to the support of this list.
>
> I successfully compiled a tool to wasm just to find out it uses the C
> system command:
> https://linux.die.net/man/3/system
> ... to call another program, https://github.com/xz-mirror/xz.
>
> The wasm program still works when I run the program through node on Linux
> CLI, but it obviously fails when I run it on a browser, with the error on
> the subject of this message:
> "failed to call xz, please confirm that xz is installed in your system"
> (this is an error message created by the tool itself, not Emscripten)
>
> Researching this specific topic is being really difficult. I tried to find
> a single example of a C program with a system call being compiled to wasm
> and running on a browser.
> But, because the words "system" and "shell" mean different things and are
> used in a variety of contexts, I get a lot of unrelated search results,
> hence I'm resorting to this discussion list.
>
> I thought about the following possible solutions:
> 1. touch the original C code to remove the system shell calls to the xz
> tool and handle the compression on JS via https://www.npmjs.com/package/xz
> 2. compile the xz tool to wasm and (somehow) make calls between the two
> wasm functions.
> (is this possible)?
>
> Any guidance is welcome.
>
> Thank you so much,
>
> Fernando
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/3e2c0c37-1f99-4df1-88c0-0040a2c14438o%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EWOU8qj6KNEVORGvnaktCujrUXVRJkW_fcaY%3DnHMOnAYw%40mail.gmail.com.

Re: wasm-ld: error: ....... not a relocatable wasm file

['Thomas Lively' via emscripten-discuss]

Hi Fernando,

There seems to be an unfortunate name clash here between the "-s
RELOCATABLE=1" option and the concept of a relocatable object. The
description of the "-s RELOCATABLE=1" option from settings.js is:

// If set to 1, we emit relocatable code from the LLVM backend; both
// globals and function pointers are all offset (by gb and fp, respectively)
// Automatically set for SIDE_MODULE or MAIN_MODULE.

This is somewhat confusing because it says "relocatable code," but then
talks about making the code position independent, which is a different
meaning of relocatable. My guess is that this Emscripten option predates
real WebAssembly object files. Anyway, the point is that this option does
not make Emscripten emit a real object file, so it is not surprising that
wasm-ld doesn't know what to do with it. You can make Emscripten produce
an object file using "-c", just like gcc or clang.

Thomas

On Sun, Jun 7, 2020 at 06:34 Fernando Bitti Loureiro <
fernando.bi...@gmail.com> wrote:

> Hi, everyone,
>
> First of all, congratulations on the amazing job of developing a tool like
> Emscripten.
> In order to learn wasm in practice, I've started to compile other people's
> libraries and, when I find any roadblock, google my way around it.
>
> I'm asking for your help because in this case, I don't know what else to
> do.
>
> This is the project: https://github.com/OpenGene/repaq.
> The moment I face an issue is when I ask Emscripten to generate the JS
> code to let me run the WASM code.
>
> These are the steps I followed.
> 1. First of all, I checked I could compile the repository using C++, by
> running make. And it worked.
>
> 2. Then I run:
> # emmake make repaq CXX=emcc CXXFLAGS="-s USE_ZLIB=1 -s RELOCATABLE=1 -s
> USE_PTHREADS=0 $CXXFLAGS"
> Emscripten also works and, despite some warnings, I get a valid repaq.wasm
> file.
>
> 3. I rename repaq.wasm to repaq.o for the next step.
> # mv repaq.wasm repaq.o
>
> 4. Now I run:
> # emcc -v repaq.o -o repaq.js -s USE_ZLIB=1 -s RELOCATABLE=1 -s
> USE_PTHREADS=0 -s EXTRA_EXPORTED_RUNTIME_METHODS="['callMain']"
> -Wl,--relocatable
> and it fails with:
> *wasm-ld: error: repaq.o: not a relocatable wasm file*
>
> The files were clearly generated with "-s RELOCATABLE=1" and I don't find
> documentation on what else to do about it.
> Any ideas?
>
> Thank you for your kind attention,
>
> Fernando
>
> *These are the versions of the tools I'm using: *
> *# emcc --version*
> *emcc (Emscripten gcc/clang-like replacement) 1.39.17
> (e4271595539cf1ca81128280cdc72f7245e700a0)*
>
> *# emcc -Wl,--version*
> *LLD 11.0.0
> (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project
> cc2349e3cf0e1f492433941b359a03fc3f746410)*
>
> *Note: I already tried combining lots of options, as well as removing
> "-lpthreads" from the make file, but I always get stuck here.*
>
> *If I use "-s USE_PTHREADS=1" I get a different type of error, related to
> atomics. However as the original project still compiles in C++ and works
> even without "-lpthreads", I preferred to test it this way in order to
> simplify.*
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/c8f14aed-8071-4f3f-9e9a-0d82f332d7cao%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EWo-NMOZay8RmX0TDWW-yiaJehiCOjw5VkrAbhMt-8kVA%40mail.gmail.com.

Re: Libvpx to WASM, facing performance issues.

['Thomas Lively' via emscripten-discuss]

The OS you use when building the wasm shouldn't affect its contents or how
fast it is. If you set EMCC_DEBUG=1 for the fast build and the slow build
you might be able to see where the difference is.

On Fri, Jun 5, 2020 at 7:40 AM MEENA N SUBBIAH  wrote:

> I finally found out why my build is slower.
>
> I build the wasm on a windows subsystem for linux, it was slower.
> The when I build the same on a mac machine it is faster.
>
> Is this expected behaviour?
>
> steps to build -
> 1. clone the code from https://github.com/ankh-g/libvpx/tree/wartc
> (branch 'wartc')
> 2. sh wasm.sh
>
> On Sunday, May 31, 2020 at 10:12:41 PM UTC+5:30, Alon Zakai wrote:
>>
>> For LTO you also need to pass -flto during the compile step (and during
>> link, and you don't need `--llvm-lto 3` any more, which was for the old
>> backend).
>>
>> If that's not it, I'd suggest comparing profiles between the builds to
>> find what is actually slower in your build.
>>
>> On Sat, May 30, 2020 at 10:04 AM MEENA N SUBBIAH 
>> wrote:
>>
>>> I am trying to compile the libvpx module to wasm.
>>> But I am facing huge performance issues.
>>>
>>> The wasm I build takes an average encode time of 1300+ milliseconds.
>>> But I found another livpx.wasm
>>> https://github.com/webrtc/apprtc/tree/wartc/src/web_app/wasm/libvpx
>>> which takes average encode time of 250+ milliseconds.
>>> Can anyone help me, Where am I going wrong.
>>>
>>> here are the compilation setting I use,
>>>
>>> to build *libvpx,*
>>>
>>>
>>> *emconfigure ../node_modules/libvpx/configure --enable-postproc
>>> --enable-multi-res-encoding --enable-temporal-denoising --enable-libyuv
>>> --size-limit=16384x16384 --enable-multithread --enable-realtime-only
>>> --disable-install-docs --disable-unit-tests --disable-vp9-decoder
>>> --disable-vp9-encoder --target=generic-gnu --extra-cxxflags="-O3 -s WASM=1
>>> -DWASM -I`dirname \`which emcc\``/system/lib/libcxxabi/include"*
>>> *emmake make*
>>>
>>> to build *libyuv,*
>>>
>>>
>>> *emcmake cmake -DCMAKE_BUILD_TYPE=Release ../node_modules/libyuvemmake
>>> make*
>>>
>>> *Final compilation,*
>>>
>>>
>>> *emcc -O3 -DWASM --bind -s STRICT=1 -s ALLOW_MEMORY_GROWTH=1 -s
>>> ASSERTIONS=0 -s NO_EXIT_RUNTIME=1 -s MALLOC=emmalloc -s MODULARIZE=1 -s
>>> FILESYSTEM=0 -s EXPORT_ES6=1 --std=c++11 -o ./my-module.js -x c++ -I
>>> ./node_modules/libvpx -I ./node_modules/libyuv/include -I build-vpx
>>> src/zcon_ss.cpp src/Utility/ZvpxCodecInst.cpp src/Utility/zvpx_encoder.cpp
>>> src/Utility/zvpx_decoder.cpp build-vpx/libvpx.a build-yuv/libyuv.a
>>> --no-entry --closure 0 --llvm-lto 3 -g0*
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/e47d2054-9a4a-4cc5-86f9-bf0072f55258%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/c177907a-af0b-43b2-ae31-1f53db84cca5o%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EVeX5AxDCG4eAMe87zK9%2Bh33YTYRDF%3Da7n7FcxT2bFrDA%40mail.gmail.com.

Re: assembly section equivalents

['Thomas Lively' via emscripten-discuss]

Yes, that's correct. WebAssembly is a Harvard architecture
, so there is no
program counter. In Emscripten there are APIs to parse the WebAssembly
binary and compute fake PC values as offsets into the binary, but I do not
recommend using them for anything. They are very low-level and heavyweight.
They were essentially added as a hack to make AddressSanitizer error
reporting work correctly.

On Fri, Dec 13, 2019 at 9:55 AM yowl yowlxx  wrote:

> Thanks, I dont need to read it, and the virtual memory addresses are what
> I want.  Are you saying there is no equivalent of a program counter?
>
> On Friday, December 13, 2019 at 12:33:21 PM UTC-5, Thomas Lively wrote:
>>
>> WebAssembly's code does not live in linear memory, so instructions and
>> functions do not have addresses at all. You could make up some numbers to
>> make your code work, but you will never be able to read the code out of
>> memory.
>>
>> On Fri, Dec 13, 2019 at 9:24 AM yowl yowlxx  wrote:
>>
>>> Hi,
>>>
>>> I'm porting some code to wasm, and wondered if there was anything
>>> equivalent to
>>>
>>> extern char __managedcode_a __asm("section$start$__TEXT$__managedcode");
>>> extern char __managedcode_z __asm("section$end$__TEXT$__managedcode")
>>>
>>> ?
>>>
>>> This is getting the start and end of code section in memory, so I guess
>>> the start will always be 0, but the end?  I could do 0x which might
>>> be ok for my purposes, but is there anything like the actual end of the
>>> wasm code?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/ef3f23a8-33d1-463e-9de4-50725eef2624%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/b4bb2d64-f5e4-4369-8b2d-61217cdf09a7%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EWUDaQmSrmbq31PAzpVTv0fWf5EsO-Ebhxq1s%2BsaPxZ5w%40mail.gmail.com.

Re: assembly section equivalents

['Thomas Lively' via emscripten-discuss]

WebAssembly's code does not live in linear memory, so instructions and
functions do not have addresses at all. You could make up some numbers to
make your code work, but you will never be able to read the code out of
memory.

On Fri, Dec 13, 2019 at 9:24 AM yowl yowlxx  wrote:

> Hi,
>
> I'm porting some code to wasm, and wondered if there was anything
> equivalent to
>
> extern char __managedcode_a __asm("section$start$__TEXT$__managedcode");
> extern char __managedcode_z __asm("section$end$__TEXT$__managedcode")
>
> ?
>
> This is getting the start and end of code section in memory, so I guess
> the start will always be 0, but the end?  I could do 0x which might
> be ok for my purposes, but is there anything like the actual end of the
> wasm code?
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/ef3f23a8-33d1-463e-9de4-50725eef2624%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EWkN45vs%2BpLxMy5v3-mrK-e2N%3DGqYRbApRPD7P%3Dox52Fw%40mail.gmail.com.

Re: [Discord] Join us to discuss WebAssembly

['Thomas Lively' via emscripten-discuss]

Ah, I found the invitation expiry settings. Here's a link that won't
expire: https://discord.gg/CYGTZTg.

On Thu, Dec 5, 2019 at 10:47 AM Brion Vibber  wrote:

> On Wed, Dec 4, 2019 at 10:26 AM 'Thomas Lively' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> Note that there is already a WebAssembly Discord server at
>> https://discord.gg/sFkS4Z. It would probably be good to consolidate on
>> that one.
>>
>
> Following that link, I get an error that the invite is expired or invalid.
>
> -- brion
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAFnWYT%3DAgng%3DgVqRLXSEWDZraQd_gQv-EOLbSOSMuCUu%2B0MD9w%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAFnWYT%3DAgng%3DgVqRLXSEWDZraQd_gQv-EOLbSOSMuCUu%2B0MD9w%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EUtUg%3DG--O_oQ_Mb7-qmdgFRsZ0jcdLdUUYtWrvze85iQ%40mail.gmail.com.

Re: [Discord] Join us to discuss WebAssembly

['Thomas Lively' via emscripten-discuss]

Yes, there's an old IRC channel at irc://irc.w3.org:6667/#webassembly, but
it doesn't get much traffic.

On Wed, Dec 4, 2019 at 1:54 PM Mehdi Sabwat  wrote:

> Hi! Is there any other official channel? Like in irc or slack?
> Thanks!
>
> On Wed, Dec 4, 2019, 19:26 'Thomas Lively' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> Note that there is already a WebAssembly Discord server at
>> https://discord.gg/sFkS4Z. It would probably be good to consolidate on
>> that one.
>>
>> On Tue, Dec 3, 2019 at 10:30 PM soloproc  wrote:
>>
>>> [image: WebAssembly.jpg]
>>>
>>>
>>>
>>> I just create a discord server named “WebAssembly” to discuss sth about
>>> it.
>>>
>>> So if you are interested to do some research or exchange some experience
>>> about best practice, JUST JOIN US !
>>>
>>>
>>> Discord: https://discord.gg/AE89YTx <https://discord.gg/AE89YTx>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/9693ba4d-059c-433e-a6bb-aaf617e1e66e%40googlegroups.com
>>> <https://groups.google.com/d/msgid/emscripten-discuss/9693ba4d-059c-433e-a6bb-aaf617e1e66e%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EV9KR_7RcKEYmzhsJ1_12ZZh9V6eA9a1-q_8-ErtYxOsA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EV9KR_7RcKEYmzhsJ1_12ZZh9V6eA9a1-q_8-ErtYxOsA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CANLCaykcsX5nezeJH0jZ%3DkyBg_3OWgPyp9pe3fdwTWX1r_4Fvg%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CANLCaykcsX5nezeJH0jZ%3DkyBg_3OWgPyp9pe3fdwTWX1r_4Fvg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EVR_qH0z_eeLpKxYjmq4%3Dq_zgB8ny7H8G2qsXdKrbEjqQ%40mail.gmail.com.

Re: [Discord] Join us to discuss WebAssembly

['Thomas Lively' via emscripten-discuss]

Note that there is already a WebAssembly Discord server at
https://discord.gg/sFkS4Z. It would probably be good to consolidate on that
one.

On Tue, Dec 3, 2019 at 10:30 PM soloproc  wrote:

> [image: WebAssembly.jpg]
>
>
>
> I just create a discord server named “WebAssembly” to discuss sth about it.
>
> So if you are interested to do some research or exchange some experience
> about best practice, JUST JOIN US !
>
>
> Discord: https://discord.gg/AE89YTx 
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/9693ba4d-059c-433e-a6bb-aaf617e1e66e%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EV9KR_7RcKEYmzhsJ1_12ZZh9V6eA9a1-q_8-ErtYxOsA%40mail.gmail.com.

Re: Semantic of WebAssembly "select" instruction?

['Thomas Lively' via emscripten-discuss]

Yes, that's right, unless the two operands have no side effects. In that
case the compiler is free to use a select because the difference is not
observable.

On Wed, Nov 13, 2019 at 11:18 AM Stéphane Letz  wrote:

> So, It means the (cond ? then : else) kind of semantic has to be
> implemented using "if" right ?
>
> Le mercredi 13 novembre 2019 20:10:20 UTC+1, Thomas Lively a écrit :
>>
>> No, it unconditionally evaluates all arguments.
>>
>> On Wed, Nov 13, 2019 at 11:09 AM Stéphane Letz  wrote:
>>
>>> Does  WebAssembly "select" instruction behaves like C/C++ (cond ? then :
>>> else),  that is compute *only* one of the two branches depending of the
>>> "cond" value?
>>>
>>> Thanks.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/06055c34-5186-4f6b-92f7-eb6a9580f893%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/972b55b8-2508-464e-830e-def000c485c2%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EUvd8H5cWU_dXc65Kt84XRuhmWpCVcavOWVxEkVQYw80w%40mail.gmail.com.

Re: Semantic of WebAssembly "select" instruction?

['Thomas Lively' via emscripten-discuss]

No, it unconditionally evaluates all arguments.

On Wed, Nov 13, 2019 at 11:09 AM Stéphane Letz  wrote:

> Does  WebAssembly "select" instruction behaves like C/C++ (cond ? then :
> else),  that is compute *only* one of the two branches depending of the
> "cond" value?
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/06055c34-5186-4f6b-92f7-eb6a9580f893%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EX6WsYD_0ZOm9w3Ptuu7PvzCXOwSX3SRtUoJqUzjh94Vg%40mail.gmail.com.

Re: Are Formal Stack Overflow Semantics In WASM + Emscripten a Possibility?

['Thomas Lively' via emscripten-discuss]

It's implemented behind the `--experimental-wasm-return-call` flag in V8
and is supported by emscripten with `-mtail-call`. I don't know about other
engines, though.

On Mon, Nov 4, 2019 at 6:38 PM Brion Vibber  wrote:

> On Mon, Nov 4, 2019, 1:50 PM 'Thomas Lively' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> If you really want to avoid the native call stack from being exhausted by
>> in-wasm recursion, another interesting avenue to pursue besides a bytecode
>> interpreter would be a continuation passing style code transformation to
>> use only `return_call` instructions from the tail call proposal, which
>> don't add new native stack frames.
>>
>
> Do you know if the tail call proposal is implemented in any engines yet?
> That would be very useful for emulators doing dynamic recompilation as well.
>
> -- brion
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAFnWYTnHkHaxOS1YHLiao7uws4vi1r-2-HUX-FkyL%2BFaAKMXXg%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAFnWYTnHkHaxOS1YHLiao7uws4vi1r-2-HUX-FkyL%2BFaAKMXXg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EVoE4r0MMx4V5M9TGhxcJC2X0hxQeCLe2eweaufB%2B00eg%40mail.gmail.com.

Re: Are Formal Stack Overflow Semantics In WASM + Emscripten a Possibility?

['Thomas Lively' via emscripten-discuss]

If you really want to avoid the native call stack from being exhausted by
in-wasm recursion, another interesting avenue to pursue besides a bytecode
interpreter would be a continuation passing style code transformation to
use only `return_call` instructions from the tail call proposal, which
don't add new native stack frames. If you combine that with a code
instrumentation to check the remaining space on the linear memory stack, I
believe you would be safe from unexpected stack exhaustion as long as you
stayed within wasm.

On Mon, Nov 4, 2019 at 12:49 PM Brion Vibber  wrote:

> There are two distinct stacks to deal with in the emscripten world: the
> native call stack and the linear memory stack.
>
> The linear memory stack is maintained by convention within the WebAssembly
> code, with the stack pointer in a global variable which points at a region
> of linear memory, and is just used for stack-allocating data that needs to
> have its address taken or otherwise cannot fit in locals. A function that
> doesn't allocate stack data might make recursive calls without ever moving
> the linear memory stack pointer, or a single function might allocate huge
> amounts of data dynamically. But you can access that stack pointer and see
> how close you are to the edge.
>
> Meanwhile the native call stack is where the "real" stack frames for
> native, JS, and WebAssembly functions live, and from WebAssembly or JS you
> have _very_ few means to introspect it. In particular note that JS/Wasm
> engines will prevent too-deep recursion safely -- but using vendor-specific
> limits with no consistency or standards.
>
> The good news is that too-deep recursion has reasonably predictable
> behavior _after the fact_ -- a trap/exception is thrown on a too-deep call
> for the native call stack, which will unwind all the Wasm functions on the
> stack up to the nearest JS catch block.
>
> The bad news is that there's no checking _ahead of time_ for the native
> call stack. You either have to try to maintain a depth counter yourself
> along with external knowledge of how deep various browser implementations
> allow the stack to get, or you let them run until they die and then clean
> up. This requires carefully keeping track of what happens when an exception
> gets thrown, and proper cleanup may require adding explicit
> exception-handling try/catch blocks to intermediate functions, which means
> call-outs between Wasm and JS.
>
> -- brion
>
>
> On Mon, Nov 4, 2019 at 12:11 PM Hostile Fork 
> wrote:
>
>> I'm asking from the perspective of writing a language interpreter...where
>> each user function call increases the stack depth of the underlying C
>> interpreter by some amount.  (Similar to a CPython implementation.)
>>
>> I know there is a tactic of rethinking your language to use a
>> bytecode--in which recursions in code the user writes don't increase the
>> stack depth of the C interpreter.  This means you expand your user's stack
>> with something like a malloc()...hence "stack overflow" isn't a
>> standards-breaking-semantic-failure-of-C, it's just conventional "memory
>> exhaustion" and you can catch it.  (Similar to a PyPy implementation.)
>>
>> But--here's my thinking: running in a browser isn't exactly "bare
>> metal".  You've got a whole JavaScript engine and an instrumentable WASM
>> backend that can pull off things like Asyncify.  Should you *really* have
>> to throw in another layer of bytecode, *just* to get enough awareness to
>> gracefully prevent stack overflow crashes?  Isn't there some kind of way to
>> say "I'm going to call this WASM function, and the compiler knows it would
>> take up N amount of stack, so tell me if I have that much before I call
>> it"?  And if it is recursive, couldn't it have some relation in it to give
>> it the self awareness to say how much just *one* call would make, along
>> with a promise to check before it decides to make another?
>>
>> Just wondering if anyone out there is thinking along these lines.  But if
>> not, then...
>>
>> ...is there any chance at being able to get some measure on a thread of
>> about how much space is left on the stack, enough to make a bit of informed
>> guesswork in recursive routines of whether they want to recurse further?
>> I'm not supper happy with the CPython method of telling users "guess an
>> integer recursion limit, if you crash irrecoverably then lower it, if you
>> think you can raise it without crashing then give it a shot".
>>
>> Thanks,
>> --Brian
>> http://hostilefork.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/5b3b2f19-96b9-46fd-b131-5af8abb86d6a%40googlegroups.com
>> 

Re: How to debug "RuntimeError: function signature mismatch"

['Thomas Lively' via emscripten-discuss]

A good first step would be to add `--profiling`, which will preserve
function names and not minify the JS.

On Fri, Nov 1, 2019 at 10:21 AM Shi Yan  wrote:

> I'm trying to compile llvm into wasm, so that I can compile and run c++
> code directly from the browser.
>
> I'm using another project as a reference: https://github.com/tbfleming/cib
>
> This project worked well, but haven't been updated for 2 years.
>
> I'm basically repeating the same, but with llvm9.
>
>
>
> I got llvm compiled into wasm, and I made a simple program to test it.
> (similar to https://github.com/tbfleming/cib/blob/master/src/clang.cpp)
>
> But as soon as I include a clang header:
>
> #include "clang/CodeGen/CodeGenAction.h"
>
> I will see a runtime error
>
> RuntimeError: function signature mismatch
> RuntimeError: function signature mismatch
>
> /home/shiy/cib/cib/src/build/clang.js:1
> var Module=typeof Module!=="undefined"?Module:{};var
> moduleOverrides={};var key;for(key in
> Module){if(Module.hasOwnProperty(key)){moduleOverrides[key]=Module[key]}}var
> arguments_=[];var thisProgram="./this.program";var
> quit_=function(status,toThrow){throw toThrow};var
> ENVIRONMENT_IS_WEB=false;var ENVIRONMENT_IS_WORKER=false;var
> ENVIRONMENT_IS_NODE=false;var ENVIRONMENT_HAS_NODE=false;var
> ENVIRONMENT_IS_SHELL=false;ENVIRONMENT_IS_WEB=typeof
> window==="object";ENVIRONMENT_IS_WORKER=typeof
> importScripts==="function";ENVIRONMENT_HAS_NODE=typeof
> process==="object"& process.versions==="object"&
> process.versions.node==="string";ENVIRONMENT_IS_NODE=ENVIRONMENT_HAS_NODE&&!ENVIRONMENT_IS_WEB&&!ENVIRONMENT_IS_WORKER;ENVIRONMENT_IS_SHELL=!ENVIRONMENT_IS_WEB&&!ENVIRONMENT_IS_NODE&&!ENVIRONMENT_IS_WORKER;if(Module["ENVIRONMENT"]){throw
> new Error("Module.ENVIRONMENT has been deprecated. To force the
> environment, use the ENVIRONMENT compile-time option (for example, -s E
> abort(RuntimeError: function signature mismatch) at Error
> at jsStackTrace (/home/shiy/cib/cib/src/build/clang.js:1:25243)
> at stackTrace (/home/shiy/cib/cib/src/build/clang.js:1:25414)
> at process.abort (/home/shiy/cib/cib/src/build/clang.js:1:22376)
> at process.emit (events.js:209:13)
> at processPromiseRejections (internal/process/promises.js:201:33)
> at processTicksAndRejections (internal/process/task_queues.js:86:32)
>
>
>
> the error message says nothing, it doesn't tell me which function has
> mismatched signature and what the signature should be.
>
> I tried
>
> "-s SAFE_HEAP=1"
> "-s ASSERTIONS=1"
>
> when compiling, but they don't give an extra messages. #"-s
> SAFE_HEAP=1" will crash the program at a different place saying memory
> alignment issue.
>
>
> I also tried the node js option node --async-stack-traces ./clang.js
>
> This gives nothing too.
>
> How can I debug this issue?
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/36ad539f-1582-45a2-9e47-851e15cbb780%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXSFHWg-SSDLh3izn6veZOsgfQmV_5GBSxxeBH3jaEh2A%40mail.gmail.com.

Re: MAIN_THREAD_EM_ASM is running on worker in a USE_PTHREADS=1 build

['Thomas Lively' via emscripten-discuss]

“'Proxying EM_ASM calls is not yet implemented in Wasm backend” is
certainly a little vague, but it means the upstream LLVM wasm backend, as
opposed to the older Fastcomp backend which also compiles to WebAssembly
but does so indirectly via asm.js.  It sounds like this feature is not yet
available in upstream-latest, unfortunately.

On Thu, Sep 5, 2019 at 23:33 Hostile Fork  wrote:

> I wanted to try out `upstream-latest`, to absorb the impact of
> "Asyncify"...looks like a superior answer to our emterpreter build, and so
> far seems fine!  Nice work!
>
> But this latest version seems to be causing problems with the
> USE_PTHREADS=1 build.  As far as I can tell, it's ignoring the
> `MAIN_THREAD_` part of MAIN_THREAD_EM_ASM().  If the request is submitted
> from a worker, it still runs on the worker.  (The same code works as
> expected in an older emsdk version, for instance with `emcc --version` of
> 1.38.28.)
>
> I dug a little into what might have changed in the code, and it looks like
> things have definitely become more nuanced, with "proxied function
> invokers":
>
>
> https://github.com/emscripten-core/emscripten/commit/60e47eff970c97b52772470806d2c81b3b1a32bf#diff-cc4345db19ff44863e9122c74e9f383fR1728
>
> I'm a bit worried about this line in particular:
>
> @no_wasm_backend('Proxying EM_ASM calls is not yet implemented in Wasm
> backend')
>
> Discussed some here as well:
>
>
> https://github.com/emscripten-core/emscripten/pull/6189#discussion_r227360878
>
> I'm not clear on what backend it would work on if not WASM, as there
> doesn't seem to be pthreads support for the JS backend.  (?)
>
> Is MAIN_THREAD_EM_ASM() supposed to work?  I didn't cook up a minimal
> example to test it, due to seeing these comments (and my usage seems pretty
> straightforward).  But if it's believed to be an error in my usage I can
> look deeper into it, just wanted to check on the meaning of these "not
> implemented" remarks first.
>
> Thanks,
> --Brian
> http://hostilefork.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/c97732a3-9626-48dc-8c47-0ec83caca0ac%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EVsEOYjVU3LBKc43KKM619doaHZzaRzsBaN_39_hCxnOg%40mail.gmail.com.

Re: "TypeError: Module.X is not a constructor" while creating C++ object in javascript code after compilation with intermediate bitcode state

['Thomas Lively' via emscripten-discuss]

Hi Pawel,

I notice that the emscripten version you’re using is quite old. Can you 
reproduce the issue with the latest version?

> On Sep 4, 2019, at 06:38, Pawel  wrote:
> 
> Hello All,
> 
> I get a TypeError: Module.ClassA is not a constructor error while creating 
> object.
> I'm having a simple header class defined in header class_a.h:
> namespace MyNamespace
> {
>   class ClassA
>   {
>   public:
> ClassA();
> void PrintName();
>   };
> }
> 
> and its implemetation in class_a.cpp
> #include 
> #include "class_a.h"
> namespace MyNamespace
> {
>   ClassA::ClassA()
>   {
> std::cout << "MyNamespace::ClassA constructor" << std::endl;
>   }
>   void ClassA::PrintName()
>   {
> std::cout << "MyNamespace::ClassA::PrintName method" << std::endl;
>   }
> }
> 
> I described in interface in class_a.idl:
> [Prefix="MyNamespace::"]
> interface ClassA
> {
>   void ClassA();
>   void PrintName();
> };
> 
> Next I create glue files with:
> python ${EMSCRIPTEN_ROOT}/tools/webidl_binder.py class_a.idl class_a_glue
> 
> And glue_wrapper.cpp containing
> #include "class_a.h"
> #include "class_a_glue.cpp"
> 
> Now I'd like to create bitcode
> em++ class_a.cpp glue_wrapper.cpp --post-js class_a_glue.js -o class_a.bc
> and finally the javascript
> em++ class_a.bc -o class_a.js
> 
> Up to now everything works fine, neither error nor warning reported.
> 
> I define simle client.js script creating object and calling method:
> var obj = new Module.ClassA();
> obj.PrintName();
> 
> When I load both class_a.jd and client.js scripts in html I get
> client.js:1 Uncaught TypeError: Module.ClassA is not a constructor at 
> client.js:1
> 
> 
> The interesting is that, if I create javascript in one step (without 
> intermediate .bc) then it works fine - I see proper printouts in browser 
> console.
> I'm however not likely going this way because I've got a bunch of classes I'd 
> like to put into one javascript, e.g.
> 
> em++ class_a.cpp glue_wrapper.cpp --post-js class_a_glue.js -o class_a.bc
> em++ class_b.cpp b_glue_wrapper.cpp --post-js class_b_glue.js -o class_b.bc
> em++ class_c.cpp c_glue_wrapper.cpp --post-js class_c_glue.js -o class_c.bc
> ...
> em++ class_a.bc class_b.bc class_c.bc ... -o class_a.js.
> 
> I'm using:
> emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 1.35.23
> clang version 3.9.0  (emscripten 1.35.23 : 1.35.23)
> 
> Why it does not work with intermediate bitcode step? Or maybe my approach is 
> incorrect?
> 
> Best regards, Paweł
> -- 
> You received this message because you are subscribed to the Google Groups 
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/emscripten-discuss/fba850f3-944d-4626-a28b-bf1d376b76aa%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/F3DE8043-BA0A-480E-B4D3-73F7882CE0DC%40google.com.

Re: Can I update the emscripten-llvm-backend by myself?

['Thomas Lively' via emscripten-discuss]

Sure, you can build tip of tree llvm and clang from source and update your 
.emscripten file to point to your local build. Random checkouts of LLVM are not 
guaranteed to work because they have not necessarily been tested alongside your 
particular version of Emscripten on our CI, but in practice they usually work 
fine. Instructions to build LLVM are here: https://llvm.org/docs/CMake.html. 

> On Aug 22, 2019, at 21:58, Wanghb Wang  wrote:
> 
> As you can  see in the 
> https://github.com/emscripten-core/emscripten/issues/9023. 
> sbc100 fix the bug “getting an Optional.h hasValue assert”.
> 
> but the latest upstream-llvm version(1.38.42-upstream ) don't contain the 
> code (cf2b8722d4e3bc4f0c106a5724778d56074e1ec7 -> 369423).
> 
> my question is: Can I update the emscripten-llvm-backend version?How to do it 
> ?
> -- 
> You received this message because you are subscribed to the Google Groups 
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/emscripten-discuss/7325d5ac-d5fa-476f-bc81-badd0c3e07e1%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/39A4AB70-9E17-445E-A51E-19841866C851%40google.com.

Re: Compile JS glue code with 'strict mode'

['Thomas Lively' via emscripten-discuss]

If all the tests pass under strict mode is there any risk that something
would break in non-strict mode, though? I was thinking not, so we could
just run all the existing tests in strict mode only.

On Mon, Aug 19, 2019 at 1:07 PM Alon Zakai  wrote:

> I worry about doubling our build times, and replacing seems too risky
> (most people run in non-strict mode). But some amount of additional
> coverage makes sense, I agree.
>
> On Mon, Aug 19, 2019 at 12:01 PM 'Sam Clegg' via emscripten-discuss <
> emscripten-discuss@googlegroups.com> wrote:
>
>> I suggest we add strict mode to our entire test suite if possible.
>>
>> On Mon, Aug 19, 2019 at 10:42 AM Alon Zakai  wrote:
>> >
>> > I understand, no problem.
>> >
>> > I have a work in progress PR for adding more comprehensive strict mode
>> testing. I see there are a few existing issues, so perhaps you hit one of
>> those. I hope to find time to work on this soon.
>> >
>> > - Alon
>> >
>> >
>> > On Mon, Aug 19, 2019 at 5:10 AM Юрий Катков  wrote:
>> >>
>> >> Unfortunatly I can't proveide example, which reproduces such behavior
>> on desktop. I received this error only on IOS 13, but I ran the same web
>> page on the previous verions of IOS (with the same "strict mode" setting,
>> if it was) :(
>> >>
>> >> and thank for your reply.
>> >>
>> >> On Thursday, August 15, 2019 at 11:42:21 PM UTC+3, Alon Zakai wrote:
>> >>>
>> >>> I don't think Safari enables strict mode by default - that would
>> break a lot of sites! But maybe this is in some special specific case? Or
>> maybe your app is run inside HTML or JS that enables strict mode?
>> >>>
>> >>> In general, we should fix strict mode bugs - please file an issue
>> with a testcase, if the errors show up in emscripten-generated code. (To
>> debug this, it's usually easier to look on a desktop browser in a
>> non-minified build.)
>> >>>
>> >>> On Wed, Aug 14, 2019 at 6:48 AM Юрий Катков 
>> wrote:
>> 
>>  Hi!
>> 
>>  I've compiled my code with emscripten 1.38.28 and now I try to
>> launch it on IOS 13. I've encountered with such error in Safari browser:
>>  [Error] Unhandled Promise Rejection: TypeError: 'arguments',
>> 'callee', and 'caller' cannot be accessed in this context.
>>  (anonymous function) (wasm_engine.js:1:164129)
>>  run (wasm_engine.js:1:164129)
>>  runCaller (wasm_engine.js:1:164033)
>>  removeRunDependency (wasm_engine.js:1:17782)
>>  receiveInstance (wasm_engine.js:1:19069)
>>  receiveInstantiatedSource (wasm_engine.js:1:19358)
>>  promiseReactionJob
>> 
>>  I'm not good in web development and JS in partial, but after some
>> investigations I think, the problem is that Safari on IOS 13 uses strict
>> mode by default, which causes error mentioned above.
>> 
>>  Could anyone suggest me how can I compile JS glue code for strict
>> mode or avoid such error in my web js code?
>> 
>>  Thanks a lot!
>> 
>>  --
>>  You received this message because you are subscribed to the Google
>> Groups "emscripten-discuss" group.
>>  To unsubscribe from this group and stop receiving emails from it,
>> send an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>  To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/a4d699b6-235d-4043-b694-2a573beff35e%40googlegroups.com
>> .
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> Groups "emscripten-discuss" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>> >> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/f818c75b-93a3-4b13-a9f1-793d4c7b6ccc%40googlegroups.com
>> .
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "emscripten-discuss" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpRgk1ZsV79FQwJZ2hNOkXJ-Fx-GP1yTnOPUGaG73TY%3DvQ%40mail.gmail.com
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to emscripten-discuss+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/emscripten-discuss/CAL_va291UoU%2Bu9TH4gVDYR8unaVyMOL8YbnauNV0dMrBpmxCXg%40mail.gmail.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> 

Re: Cleaning up old branches/PRs/issues

['Thomas Lively' via emscripten-discuss]

Sounds great to me. I can't imagine that anything more than two years old
could still be useful. And whoever cares about an old branch probably still
has it sitting around locally.

On Fri, Aug 16, 2019 at 1:47 PM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:

> I'm thinking of going through old branches/PRs/issues and closing any
> anything that hasn't seen any activity in a certain amount of time.
>
> Does any object to anything without activity in, say, the last 2
> years, being speculatively closed out?  PRs and issues can obviously
> be re-opened.   Branches (without PRs) are harder to restore so I
> might check in with individuals first.
>
> Thoughts?
>
> cheers,
> sam
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_RZmUKKBBw6aFd04_auYTEjYO8AKV%2BepGeMrAmksFBLw%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EUf_qWqBnVBE0whmPo3tNd4To-6Bg-GngYRUHHP8W4hzw%40mail.gmail.com.

Re: Atomics issue when using latest-upstream

['Thomas Lively' via emscripten-discuss]

-pthread and -s USE_PTHREADS should be identical. If they are not that is a bug 
we should look into. If you could file an issue on the Emscripten repository 
with details that would be great.

Either flag should work fine for compiling dependencies.

> On Aug 12, 2019, at 09:05, Mehdi Sabwat  wrote:
> 
> Hi Thomas, 
> 
> Thank you for your answer it seems the difference between -s USE_PTHREADS=1 
> and -pthread lies within the JS code generation. But I am not sure. 
> 
> My case is I am cross compiling a library that I will use as a module for a 
> main.c, the main file will be compiled and linked with -s USE_PTHREADS=1 and 
> other options (WEBGL, PTHREAD_PROXY etc...), do I need to compile all the 
> dependencies with -s USE_PTHREADS=1 or is -pthread enough?
> 
> Thanks ! 
> Regards
> 
>> On Wednesday, July 24, 2019 at 11:55:07 PM UTC+2, Thomas Lively wrote:
>> Hi Dylan,
>> 
>> Here's what these errors mean in more detail.
>> 
>> wasm-ld: error: 'atomics' feature is used by d1_lib.o, so --shared-memory 
>> must be used
>> 
>> This one means that `dl_lib.o` was compiled with -pthread already (-pthread 
>> enables the 'atomics' feature), so its atomic operations have been lowered 
>> to real atomic WebAssembly instructions. However, because you're not passing 
>> -pthread at link time, the linker tries to produce a module with an unshared 
>> memory, which would make those atomic instructions invalid.
>> 
>> wasm-ld: error: Target feature 'atomics' used in d1_lib.o is disallowed by 
>> ConcurrentScheduler.cpp.o. Use --no-check-features to suppress.
>> 
>> This line tells us that ConcurrentScheduler.cpp.o was compiled without 
>> -pthread, which means its atomic operations were lowered to non-atomic 
>> WebAssembly instruction because the atomics feature was not enabled. That 
>> means that ConcurrentScheduler.cpp.o is not safe to link with dl_lib.o 
>> because the resulting program would not be thread-safe, even if the program 
>> was thread-safe at the source level. When using the LLVM backend, the 
>> wasm-ld linker helpfully recognizes this error and does not let you link an 
>> unsafe program. Fastcomp would just silently link your program into a 
>> thread-unsafe binary.
>> 
>> As Mehdi said, you can either make sure to use -pthread when building all 
>> your objects and libraries and at link time to get a properly thread-safe 
>> binary out, or alternatively you can make sure not to pass -pthread for any 
>> of the objects and libraries to get a single-threaded version of the binary 
>> that will run on any engine.
>> 
>> Let me know if I you want more detail on anything :)
>> 
>>> On Wed, Jul 24, 2019 at 2:41 PM Dylan Staley  wrote:
>>> By adding the pthreads flag, will that change the behavior of the generated 
>>> WASM module? I know that browsers like Chrome have experimental support for 
>>> webassembly threads, but I'm aiming for a WASM module that works in older 
>>> versions of Chrome as well.
>>> 
 On Wed, Jul 24, 2019, 2:34 PM Mehdi Sabwat  wrote:
 I think it's there, https://reviews.llvm.org/D59625 . The backend seems to 
 disallow linking with objects that use atomics features and are not tagged 
 as such. That's how I have understood it. I fixed it in my build by adding 
 pthread to my CFLAGS. 
 You don't seem to have CFLAGS so prepending cmake with CFLAGS="-pthread" 
 should do the trick.
 Let us know if it works :)
 
> On Wednesday, July 24, 2019 at 11:04:29 PM UTC+2, Dylan Staley wrote:
> Hello! I recently heard about the new WebAssembly backend, and wanted to 
> give it a try to compare against the fastcomp backend. I've successfully 
> compiled this project using `latest`, but when I switch to 
> `latest-upstream` I get the following issue during linking:
> 
> ```
> wasm-ld: error: 'atomics' feature is used by d1_lib.o, so --shared-memory 
> must be used
> wasm-ld: error: Target feature 'atomics' used in d1_lib.o is disallowed 
> by ConcurrentScheduler.cpp.o. Use --no-check-features to suppress.
> ```
> 
> The actual command that failed was:
> ```
> shared:ERROR: '/home/staley_dylan/emsdk/upstream/bin/wasm-ld -o 
> /tmp/emscripten_temp_DthpaW/td_wasm.wasm --allow-undefined 
> --import-memory --import-table --lto-O0 
> CMakeFiles/td_wasm.dir/td/telegram/td_emscripten.cpp.o libtdjson_static.a 
> tdactor/libtdactor.a libtdjson_private.a libtdclient.a libtdcore.a 
> tdnet/libtdnet.a ../crypto/lib/libssl.a tddb/libtddb.a 
> tdactor/libtdactor.a tdutils/libtdutils.a sqlite/libtdsqlite.a 
> ../crypto/lib/libcrypto.a 
> /home/staley_dylan/.emscripten_cache/wasm-obj/libz.a 
> /home/staley_dylan/.emscripten_cache/wasm-obj/libc.a 
> /home/staley_dylan/.emscripten_cache/wasm-obj/libcompiler_rt.a 
> /home/staley_dylan/.emscripten_cache/wasm-obj/libc-wasm.a 
> /home/staley_dylan/.emscripten_cache/wasm-obj/libc++-noexcept.a 
> 

Re: Compiling Issues when using Xmmintrin.h

['Thomas Lively' via emscripten-discuss]

Yes, it looks like you're using the old fastcomp backend, but SIMD and
other post-MVP WebAssembly features are only supported with the new LLVM
backend. If you're using the emsdk, you can try installing and activating
the `latest-upstream` tag instead of just `latest`.

On Wed, Aug 7, 2019 at 1:34 PM Jonathan Esteban  wrote:

> Okay, so I'll try replacing the intrinsics we are using with the ones
> WebAssembly supports. I swapped #include  with #include
> 
>
> and added the flag -msimd128
>
> so now I'm running:
>
> em++ -msimd128 -g -I src/lib/ -I boost src/lib/pke/multiparty.cpp -v
>
>
>
> But I'm getting the following errors:
> In file included from src/lib/pke/multiparty.cpp:7:
>
> In file included from src/lib/pke/multiparty.h:10:
>
> In file included from src/lib/Common/Defines.h:9:
>
> /home/jonathanesteban/emsdk/fastcomp/emscripten/system/include/wasm_simd128.h:482:18:
> error: use of undeclared
>   identifier '__builtin_wasm_bitselect'
>
>   return (v128_t)__builtin_wasm_bitselect((__i32x4)a, (__i32x4)b,
> (__i32x4)mask);
>  ^
>
> /home/jonathanesteban/emsdk/fastcomp/emscripten/system/include/wasm_simd128.h:492:10:
> error: use of undeclared
>   identifier '__builtin_wasm_any_true_i8x16'
>
>   return __builtin_wasm_any_true_i8x16((__i8x16)a);
> Any idea of why this is happening?
>
> Thanks
>
> On Wednesday, August 7, 2019 at 4:03:12 PM UTC-4, Thomas Lively wrote:
>>
>> That's right. Those particular intrinsics are specific to x86 platforms.
>> You can use the WebAssembly SIMD intrinsics from
>> https://github.com/emscripten-core/emscripten/blob/incoming/system/include/wasm_simd128.h
>>  instead,
>> though.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/f5c1f2cd-df01-4292-835b-3bcb8121a027%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXUdVzb0duUe-rXxMR19iKdxgsK%3DPk8AmGyHuA%2BAMu4RA%40mail.gmail.com.

Re: Compiling Issues when using Xmmintrin.h

['Thomas Lively' via emscripten-discuss]

That's right. Those particular intrinsics are specific to x86 platforms.
You can use the WebAssembly SIMD intrinsics from
https://github.com/emscripten-core/emscripten/blob/incoming/system/include/wasm_simd128.h
instead,
though.

On Wed, Aug 7, 2019 at 11:19 AM Jonathan Esteban  wrote:

> Thanks for the prompt reply! I've read through the links you provided.
> What I'm getting at is that there's no way to compile code that uses SIMD
> intrinsics? (i.e. emmintrin.h)
>
> On Wednesday, August 7, 2019 at 1:29:08 PM UTC-4, Thomas Lively wrote:
>>
>> Hi, using native SIMD intrinsics is not supported with WebAssembly
>> because emulating native SIMD via WebAssembly SIMD will lead to unexpected
>> slowdowns. See this recent thread for more details:
>> https://groups.google.com/forum/#!msg/emscripten-discuss/bp_iubXU3BE/vI4opCduCQAJ
>>  and
>> see
>> https://emscripten.org/docs/porting/simd.html#porting-simd-code-targeting-webassembly
>>  for
>> more information on using WebAssembly's SIMD.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/5866ecc7-c122-4084-9429-2fd07c5b09fc%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EW%3DKOuAkfiEkfoiiyq270%3DGAGjYGm4%2BRRXcg7cojFZYZA%40mail.gmail.com.

Re: Compiling Issues when using Xmmintrin.h

['Thomas Lively' via emscripten-discuss]

Hi, using native SIMD intrinsics is not supported with WebAssembly because
emulating native SIMD via WebAssembly SIMD will lead to unexpected
slowdowns. See this recent thread for more details:
https://groups.google.com/forum/#!msg/emscripten-discuss/bp_iubXU3BE/vI4opCduCQAJ
and
see
https://emscripten.org/docs/porting/simd.html#porting-simd-code-targeting-webassembly
for
more information on using WebAssembly's SIMD.

On Wed, Aug 7, 2019 at 9:25 AM Jonathan Esteban  wrote:

> Hi all,
>
> I'm trying to compile a file using this command:
>
> $em++ -g -I src/lib/ -I boost src/lib/pke/multiparty.cpp -v
>
>
> However, I am getting this error:
>
> In file included from src/lib/pke/multiparty.cpp:7:
>
> In file included from src/lib/pke/multiparty.h:10:
>
> In file included from src/lib/Common/Defines.h:9:
>
> In file included from
> /home/user/emsdk/fastcomp/fastcomp/lib/clang/6.0.1/include/emmintrin.h:27:
>
> In file included from
> /home/user/emsdk/fastcomp/fastcomp/lib/clang/6.0.1/include/xmmintrin.h:27:
>
> /home/user/emsdk/fastcomp/fastcomp/lib/clang/6.0.1/include/mmintrin.h:47:5:
> error: use of undeclared
>   identifier '__builtin_ia32_emms'; did you mean '__builtin_isless'?
>
> __builtin_ia32_emms();
>
>
> When I compile using g++ I get no error. I think g++ is using another
> source for its emmintrin.h. I need to use emmintrin.h as it is used in
> Defines.h through:
>
> #include 
>
> Any thoughts? I'm at a loss of ideas and I'm very new to Emscripten and
> building projects in general. Let me know if you need more debugging info.
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/77bcb151-7497-4fe9-87a8-43137473538a%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EX9dMK_UCup%2B5k3oM0-hcfPtwS%2BdYvTTkRqXrR%2BXugnSg%40mail.gmail.com.

Re: Problem with SIMD emulation (LLVM ERROR: Unsupported integer vector type with numElems: 2, primitiveSize: 64!)

['Thomas Lively' via emscripten-discuss]

Hi, unfortunately those headers you are using have nothing to do with
WebAssembly and will not enable you to compile code using x86 intrinsics
and targeting WebAssembly. I've filed an issue for this here:
https://github.com/emscripten-core/emsdk/issues/309. Clang is giving you a
warning about `-msse2` because that flag only works for x86 targets; SSE2
is an x86 feature, not a WebAssembly feature. Notice that you are also
getting a large number of warnings about unrecognized builtin functions
like `__builtin_ia32_emms`. These builtin functions are used by the
mmintrin.h header you included but only exist when targeting x86, not
WebAssembly.

You can read more about using WebAssembly SIMD intrinsics here:
https://emscripten.org/docs/porting/simd.html#porting-simd-code-targeting-webassembly.
Please also keep in mind that using emulated SIMD is slower than not using
SIMD at all.

On Sat, Aug 3, 2019 at 8:02 AM Flix  wrote:

>
> I've just added all the related stuff to my nudge fork here
> https://github.com/Flix01/nudge (in case someone is interested).
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/53c8f539-217e-44b9-922f-722ad63078a1%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EW8q7APbHyU6catg6AhSgOWORqX011EXXL2%2B5ip7BuWrw%40mail.gmail.com.

Re: memmove / bulk memory operations proposal status

['Thomas Lively' via emscripten-discuss]

Hmm yeah I was worried that might happen. We’re going to have to do some 
science to figure out where it is actually beneficial to use the bulk memory 
instructions. Alternatively we can just pester engine implementers to optimize 
them better. 

> On Jul 12, 2019, at 09:38, Lilit Darbinyan  wrote:
> 
> oops typo - it's twice as slow WITH the flag. 
> 
>> On Friday, July 12, 2019 at 5:37:52 PM UTC+1, Lilit Darbinyan wrote:
>> Thanks!
>> 
>> Interestingly it's twice as slow without the flag. It's now 40ms instead of 
>> the 20ms. To summarize:
>> 
>> Fastcomp  80ms
>> LLVM  20ms
>> LLVM with -mbulk-memory   40ms
>> 
>> The profiler now shows this as the hot path instead of memmove:
>> 
>> std::__2::vector 
>> >::insert(std::__2::__wrap_iter, unsigned long, double const&)
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/emscripten-discuss/7cf8a87b-bf54-49ea-96a1-cb337c903546%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/654F8E88-D6B6-4085-98FA-F4AFD3B0AF71%40google.com.
For more options, visit https://groups.google.com/d/optout.

Re: memmove / bulk memory operations proposal status

['Thomas Lively' via emscripten-discuss]

A memory.copy instruction should be emitted if you pass -mbulk-memory while 
using the LLVM backend. I’d be very interested in how that affects your 
benchmark.

> On Jul 12, 2019, at 09:01, Lilit Darbinyan  wrote:
> 
> I have a benchmark where I insert into the front of a vector in a loop 1k 
> times, which causes the vector to grow continuously. 
> 
> This was pretty slow with the Fastcomp generated Wasm binary (~80ms), and 
> sure enough profiling showed that the hot path was memmove. 
> I have now switched to the new LLVM upstream backend, and it's much faster 
> now but not as fast as I expect (~20ms), and memmove is still showing as the 
> most time consuming thing. 
> 
> I have inspected the generated wasm binary and don't see any of the new bulk 
> memory operations there, so my questions are:
> 
> - Does the new LLVM upstream backend support bulk memory operations?
> - If not, then why am I seeing this speedup by switching to the LLVM backend? 
> 
> The benchmark code can be found here: 
> https://github.com/ldarbi/wasm-scratchpad/tree/master/memmove
> -- 
> You received this message because you are subscribed to the Google Groups 
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/emscripten-discuss/eb5441fc-02d2-4894-8559-6d7ea5ea1e61%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/DEB4BF6E-890E-41B2-BCD2-C444A7A1E096%40google.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Dynamic linking] New and delete operators not exported or inaccessible in SIDE_MODULE

['Thomas Lively' via emscripten-discuss]

Yes, opening a GitHub issue on the Emscripten repository would be great. 

> On Jul 7, 2019, at 02:00, Tapan Anand  wrote:
> 
> Yeah I would like to. How do I go about doing that? Just create a github 
> issue on emscripten repository? I think this is an important feature that is 
> indispensable for using dynamic linking in production.
> 
>> On Wednesday, 3 July 2019 22:21:33 UTC+5:30, Sam Clegg wrote:
>> On Sat, Jun 29, 2019 at 8:31 AM Tapan Anand  wrote: 
>> > 
>> > Hi Sam, 
>> >I see that error during runtime, when that branch of code is hit. Is 
>> > there a way for them to atleast show up at load time so I can be sure that 
>> > user wouldn't encounter any new errors in production? 
>> > 
>> 
>> There is no way currently but it could be added.  Do you want to open 
>> an issue requesting this feature? 
>> 
>> 
>> > On Saturday, 29 June 2019 01:17:22 UTC+5:30, Sam Clegg wrote: 
>> >> 
>> >> On Fri, May 31, 2019 at 1:25 AM Tapan Anand  
>> >> wrote: 
>> >> > 
>> >> > So does that mean its possible to miss some missing symbols as well 
>> >> > since runtime errors seems to be the only way to determine them? 
>> >> 
>> >> Yes, they are currently runtime errors, because dynamic linking 
>> >> happens at runtime.   Are you seeing them show at at startup or after 
>> >> main runs?   We should at least be able to ensure these are load time 
>> >> errors. 
>> >> 
>> >> Ideally we would build a system where the MAIN_MODULE and the 
>> >> SIDE_MODULE can be built in such a way that can know that list of 
>> >> symbols needed by the other modules.  However because we have a lot of 
>> >> circular dependencies this could prove a little tricky. 
>> >> 
>> >> > 
>> >> > On Friday, 31 May 2019 03:49:27 UTC+5:30, Alon Zakai wrote: 
>> >> >> 
>> >> >> Yes, in general the optimizer may remove anything it does not see is 
>> >> >> used, in normal compilation, and in main module/side module mode 2. 
>> >> >> It's possible some things stay alive anyhow since they are used by 
>> >> >> other things. But if nothing else uses it, you must add it to the 
>> >> >> exports yourself, or the optimizer may remove it. 
>> >> >> 
>> >> >> On Wed, May 29, 2019 at 1:10 PM Tapan Anand  
>> >> >> wrote: 
>> >> >>> 
>> >> >>> Thanks for the quick reply Alon! 
>> >> >>> The C library functions puts and printf work with MAIN_MODULE=1 but 
>> >> >>> the new and delete operator errors still persist if I don't manually 
>> >> >>> export them. 
>> >> >>> Regarding - "which means you need to carefully pick what is kept 
>> >> >>> alive for the other modules", so you mean we have to add these 
>> >> >>> mangled names in the export list if we use MAIN_MODULE=2 and there is 
>> >> >>> no other way to avoid this? MAIN_MODULE=1 creates a huge .js and 
>> >> >>> .wasm file and hence ends up increasing the MAIN_MODULE size while 
>> >> >>> the purpose of dynamic linking for me is to reduce its size. 
>> >> >>> Also, I got to know about new and delete via runtime errors, but what 
>> >> >>> if I some part of code is not encountered while testing (and hence no 
>> >> >>> runtime error occurs)? That may cause unknown crashes when the user 
>> >> >>> uses the app for example, is that expected? Or there is a way to know 
>> >> >>> unresolved symbols in advance using some technique? 
>> >> >>> 
>> >> >>> On Thursday, 30 May 2019 00:00:45 UTC+5:30, Alon Zakai wrote: 
>> >>  
>> >>  This is probably because of MAIN_MODULE=2, which means you need to 
>> >>  carefully pick what is kept alive for the other modules. Does this 
>> >>  work with =1? If so then that's the issue. The test suite has a 
>> >>  bunch of examples for mode 2, that might help. 
>> >>  
>> >>  On Wed, May 29, 2019 at 3:40 AM Tapan Anand  
>> >>  wrote: 
>> >> > 
>> >> > Hi, 
>> >> > 
>> >> > I was trying to use dynamic linking using dlopen with emscripten 
>> >> > compiler version 1.38.28 and encountered the following problem: 
>> >> > 
>> >> > 1. When I try to use vector in the SIDE_MODULE, it can't seem to 
>> >> > find the new and delete operators in the Module variable. 
>> >> > 
>> >> > 2. The command I use to build main and side module are: 
>> >> > 
>> >> > 
>> >> > em++ doubler.cpp -o doubler.wasm -s SIDE_MODULE=1 -O3 -s 
>> >> > "EXPORTED_FUNCTIONS=['_doubler']" 
>> >> > EMCC_FORCE_STDLIBS=1 em++ main.cpp -O3 -s WASM=1 -s MAIN_MODULE=2 
>> >> > -o dynlink.js -s "EXPORTED_FUNCTIONS=['_main', '_clock', 
>> >> > '_tripler', '_printf', '_puts']"  -s 
>> >> > "DEFAULT_LIBRARY_FUNCS_TO_INCLUDE=['clock']" -s FORCE_FILESYSTEM=1 
>> >> > --pre-js prejs.js 
>> >> > 
>> >> > 
>> >> > The prejs file here is there to use FS.createLazyFile to cause lazy 
>> >> > loading of the side module. 
>> >> > 
>> >> > If I change the exported function list in main_module to `['_main', 
>> >> > '_clock', '_tripler', '__Znwm', '__ZdlPv', '_printf', '_puts']` It 
>> >> 

Re: [LLVM WASM backend] - pthread_local causes a compiler crash

['Thomas Lively' via emscripten-discuss]

Unfortunately thread local storage has not been implemented in the WebAssembly 
LLVM backend yet, although we’re just starting to work on it now. I saw the 
LLVM bug you filed, and we will definitely take a look at how we can avoid the 
crash you’re seeing or at least give a more helpful error message until TLS 
support is complete.

For now you can try using the pthreads library TLS rather than language-level 
TLS. I believe that should work.

> On Jul 4, 2019, at 12:43, Mehdi Sabwat  wrote:
> 
> Hi, 
> 
> Putting this here because I think it could lead to an interesting discussion. 
> (and because by writing things down, I can understand them better. This is 
> (very) new to me)
> 
> cross compiling this 
> [thread_local]$ cat main.c
> #include 
> #include 
> 
> thread_local int a;
> 
> int main()
> {
>   printf("%d\n", a);
> }
> 
> with:
> 
> emcc -pthread main.c
> 
> or:
> emcc -s USE_PTHREADS=1
> 
> or:
> clang-9 --target=wasm32-unknown-emscripten 
> -I../../emsdk/upstream/emscripten/system/include/libc/ -pthread main.c) 
> 
> leads to a SIGABORT because this assertion fails:
> virtual uint64_t (anonymous 
> namespace)::WasmObjectWriter::writeObject(llvm::MCAssembler &, const 
> llvm::MCAsmLayout &): Assertion `Sec.getKind().isMetadata()' failed
> 
> WasmObjectWriter fails to write object code because of the IR, which has 
> weird or unrecognized sections. Question is, if we change the code to 
> initialise the sections, would it be recognised by WASM if so, how ?  :) 
> there doesn't seem to be any reference of thread_local in WebAssembly.
> 
> Since pthread support is experimental in WASM (although we can already do a 
> lot of things), I wanted to know if there was something we could do to work 
> around it?
> 
> Complete logs are here.
> 
> Cheers!
> -- 
> You received this message because you are subscribed to the Google Groups 
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/emscripten-discuss/78f61504-4e78-4afb-a4be-3e0314f5e29f%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/2DE1A1C5-73E6-42E5-BAA8-ED54CB8D0F66%40google.com.
For more options, visit https://groups.google.com/d/optout.

Re: WebAssembly bulk memory operations

['Thomas Lively' via emscripten-discuss]

We are working quickly toward being able to make the LLVM backend the
default. It is just short of feature parity with the fastcomp backend, but
as you've noticed, most new feature development is happening with the LLVM
backend. I believe the LLVM backend should be ready to use for everything
except threads right now, and my impression is that it produces code that
is at least as good as fastcomp-produced code, although I'm not sure of the
exact status of that. Note that both the LLVM backend and the fastcomp
backend use Binaryen to optimize and transform the output code.

On Thu, May 16, 2019 at 4:09 PM Soeren Balko  wrote:

> Thanks for sharing this! I'm generally wondering in what shape the LLVM
> backend is at this stage. We've so far used Binaryen, but it seems that new
> WebAssembly features (SIMD, bulk mem ops) are coming to LLVM first. Would
> you still consider the LLVM-based wasm backend to be experimental? Also,
> how does it stack up in terms of performance (of the emitted WebAssembly
> "binary") when compared with Binaryen?
>
> On Friday, May 17, 2019 at 4:05:40 AM UTC+10, Thomas Lively wrote:
>>
>> If you pass -mbulk-memory to emcc while using the LLVM backend, it will
>> automatically lower memcpy, memmove, and memset to use their bulk memory
>> instruction equivalents. That should work today.
>>
>> The plan is to land conditional segment initialization using memory.init
>> and data.drop instructions in the linker once bulk memory operations ship
>> by default in stable chrome. That will allow emscripten to use threads
>> without separate memory init files.
>>
>> On Wed, May 15, 2019 at 9:56 PM Soeren Balko  wrote:
>>
>>> Just saw that Chrome has WebAssembly bulk memory operations in beta. Are
>>> there any short-term plans to make these available behind a flag in
>>> Emscripten?
>>>
>>> Thanks,
>>> Soeren
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/f2f90663-974d-497c-9bbc-b29026483a49%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/4270df8a-4cfc-4057-b161-1133888cfe1e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EXbLTCpmpDki6PkEap9iUMswo4S6t5PmXjSfQUySyG%3Duw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: WebAssembly bulk memory operations

['Thomas Lively' via emscripten-discuss]

If you pass -mbulk-memory to emcc while using the LLVM backend, it will
automatically lower memcpy, memmove, and memset to use their bulk memory
instruction equivalents. That should work today.

The plan is to land conditional segment initialization using memory.init
and data.drop instructions in the linker once bulk memory operations ship
by default in stable chrome. That will allow emscripten to use threads
without separate memory init files.

On Wed, May 15, 2019 at 9:56 PM Soeren Balko  wrote:

> Just saw that Chrome has WebAssembly bulk memory operations in beta. Are
> there any short-term plans to make these available behind a flag in
> Emscripten?
>
> Thanks,
> Soeren
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/f2f90663-974d-497c-9bbc-b29026483a49%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EU1uHR4G85MjusFVimYt98PikZ%2BaZs_UnDAx1yh2GYp_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Installing all upstream tools through EMSDK?

['Thomas Lively' via emscripten-discuss]

Try ‘emsdk install latest-upstream’, but what are you doing that requires all 
the unstable tip of tree tools? That should only be useful if you are 
developing the tools themselves. 

> On May 11, 2019, at 11:28, Osman Zakir  wrote:
> 
> I want to install the upstream stuff mentioned in the lkgr.json file in the 
> `upstream` folder.  How do I do that through the EMSDK?  Running the "emsdk 
> list" command gives me this output:
> 
> "
> The following precompiled tool packages are available for download:
>clang-e1.30.0-64bit
>clang-e1.34.1-64bit
>clang-e1.35.0-64bit
>clang-e1.37.1-64bit
>clang-e1.38.30-64bit
>clang-e1.38.31-64bit
>node-4.1.1-32bit
>node-4.1.1-64bit
>node-8.9.1-32bit
>node-8.9.1-64bit
>python-2.7.13.1-32bit
>python-2.7.13.1-64bit
>python-3.5.4-32bit
>python-3.5.4-64bit
>java-7.45-32bit
>java-7.45-64bit
>java-8.152-32bit
>java-8.152-64bit
>spidermonkey-37.0.1-64bit
>spidermonkey-nightly-2015-04-12-64bit
>git-1.9.4
>emscripten-1.30.0
>emscripten-1.34.1
>emscripten-1.35.0
>emscripten-1.37.1
>emscripten-1.38.30
>emscripten-1.38.31
>vs-tool-0.9.4
>crunch-1.03
>gnu-2.5.4
>mingw-7.1.0-64bit
> The following tools can be compiled from source:
>clang-tag-e1.38.30-32bit
>clang-tag-e1.38.31-32bit
>clang-tag-e1.38.30-64bit
>clang-tag-e1.38.31-64bit
>clang-incoming-32bit
>clang-incoming-64bit
>clang-master-32bit
>clang-master-64bit
>upstream-clang-master-32bit
>upstream-clang-master-64bit
>emscripten-tag-1.38.30-32bit
>emscripten-tag-1.38.31-32bit
>emscripten-tag-1.38.30-64bit
>emscripten-tag-1.38.31-64bit
>binaryen-tag-1.38.30-32bit
>binaryen-tag-1.38.31-32bit
>binaryen-tag-1.38.30-64bit
>binaryen-tag-1.38.31-64bit
>emscripten-incoming-32bit
>emscripten-master-32bit
>emscripten-incoming-64bit
>emscripten-master-64bit
>binaryen-master-32bit
>binaryen-master-64bit
> The following precompiled SDKs are available for download: (Run "git pull" 
> followed by "./emsdk update-tags" to pull in the latest list)
>  sdk-1.30.0-64bit
>  sdk-1.34.1-64bit
>  sdk-1.35.0-64bit
>  sdk-1.37.1-64bit
>  sdk-1.38.30-64bit
>  sdk-1.38.31-64bit
> The following SDKs can be compiled from source:
>  sdk-incoming-32bit
>  sdk-wasm-master-32bit
>  sdk-incoming-64bit
>  sdk-wasm-master-64bit
>  sdk-master-32bit
>  sdk-master-64bit
>  sdk-tag-1.38.30-32bit
>  sdk-tag-1.38.31-32bit
>  sdk-tag-1.38.30-64bit
>  sdk-tag-1.38.31-64bit
> Items marked with * are activated for the current user.
> To access the historical archived versions, type 'emsdk list --old'
> "
> 
> I don't understand which one to get if I want upstream LLVM from the LLVM 
> GitHub repo.  Also, I was thinking it might be `sdk-wasm-master-64bit` and 
> therefore tried to install that, but I got stuck on building Clang.  
> 
> Please note that I what I mean by it being stuck on building Clang is that it 
> failed with an error:
> 
>> Build failed due to exception!
>> Working directory: C:/emsdk/clang/upstream\build_master_vs2017_64
>> Command '['C:\\Program Files (x86)\\Microsoft Visual 
>> Studio\\2017\\Community\\MSBuild/15.0/Bin/amd64\\MSBuild.exe', '/t:Build', 
>> '/p:Configuration=Release', '/p:Platform=x64', '/nologo', 
>> '/verbosity:minimal', 'LLVM.sln']' returned non-zero exit status 1
>> Installation failed!
>  
> Another question I want to ask is this: is it possible to just have the EMSDK 
> download the necessary files for the SDKs or tools I want and then use CMake 
> to build them myself?
> 
> Speaking of LLVM/Clang, if that SDK has the upstream version, it should have 
> WebAssembly as a target to build rather than an experimental target because 
> in LLVM 9 it's not an experimental target anymore and is included by default 
> (`-DLLVM_TARGETS_TO_BUILD=all` is the default setting, and WebAssembly is 
> included under "all").  But I noticed that the EMSDK uses the setting 
> `-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly`.  Doesn't that mean it's 
> an older version of LLVM?  Also, is it vanilla LLVM built to target 
> WebAssembly, or is it Fastcomp?
> 
> I want to get the lkgr stuff.  And preferably I want EMSDK to use my own 
> global installations of Java, Python and Node.  If possible.  Please help.  
> Thanks in advance.
> -- 
> You received this message because you are 

Re: Using LLVM Directly to Generate WebAssembly Module (vanilla LLVM targeting WebAssembly)?

['Thomas Lively' via emscripten-discuss]

Yes, you could try using WASI and the WASI web polyfill instead. I haven't
played with that myself so I'm not sure how it works yet.

*From: *Osman Zakir 
*Date: *Thu, May 9, 2019 at 1:51 PM
*To: *emscripten-discuss

There should be a way to get sysroot_wasi to work under Windows, right?  I
> could try to use that (I need to how first, though).
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/543abae6-f7d0-401a-a625-b2551ff2371d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EUxqc12p05W-JR0X8TwEmYqFTu-Lp%3Dg1wrusvDwPVUJsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using LLVM Directly to Generate WebAssembly Module (vanilla LLVM targeting WebAssembly)?

['Thomas Lively' via emscripten-discuss]

Unfortunately that is a recipe for an avalanche of problems and because
there are so many components being developed in parallel there is
essentially no way to make that work manually without being at tip of tree
of anything, which is inherently unstable. emsdk gives you complete control
over the version of emscripten you have installed and lets you switch
between versions easily. We cannot provide support for trying to roll your
own toolchain when emsdk would already do what you need.

*From: *Osman Zakir 
*Date: *Thu, May 9, 2019 at 1:30 PM
*To: *emscripten-discuss

The reason I don't want to use Emsdk is mainly because I want to have
> control over the installation of Emscripten and the version of Clang I'm
> using.
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/5675fc59-ec8a-4908-8a55-be23a23383ca%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EVDRu4-260k_xFkmoYZ-AEp9HoYs7G6gSXa%3D6e3p4y1PA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using LLVM Directly to Generate WebAssembly Module (vanilla LLVM targeting WebAssembly)?

['Thomas Lively' via emscripten-discuss]

Yes, what I meant about building your own installation of emscripten is
building LLVM and BInaryen and the other tools yourself. There shouldn't be
any need to do that. In particular, if you get your checkout of LLVM and
the rest of the emscripten tools from different places I would not expect
them to work together correctly. That is why you are seeing errors when
trying to use the tools. Using emsdk will get you a complete installation
of emscripten that does not require you to build anything yourself and it
should not have any of the issues you are seeing.

*From: *Osman Zakir 
*Date: *Thu, May 9, 2019 at 1:24 PM
*To: *emscripten-discuss

I do have Emscripten.  I just have a problem with gen_struct_info due to
> which I can't generate JavaScript glue code and a WebAssembly module when
> not using the "-s SIDE_MODULE=1" setting and can't generate a decent,
> non-corrupt (I assume) WebAssembly module when using the "-s SIDE_MODULE"
> setting.  Didn't you look at the GitHub issue I linked to?
>
> This are the contents of the first post there:
>
> This time I've built LLVM 9.0.0 with the -A x64 and -Thost=x64 flags and
> also built Binaryen and Emscripten's asm.js optimizer again, then tried to
> compile some C code to WebAssembly.  But I get the same error as before:
>
> Traceback (most recent call last):
>>   File "C:\emscripten\emcc.py", line 3316, in 
>> sys.exit(run(sys.argv))
>>   File "C:\emscripten\emcc.py", line 1947, in run
>> final = shared.Building.emscripten(final, target + '.mem',
>> js_libraries)
>>   File "C:\emscripten\tools\shared.py", line 2197, in emscripten
>> emscripten.run(infile, outfile, memfile, js_libraries)
>>   File "C:\emscripten\emscripten.py", line 2560, in run
>> shared.Settings.STRUCT_INFO =
>> shared.Cache.get(generated_struct_info_name, ensure_struct_info)
>>   File "C:\emscripten\tools\cache.py", line 133, in get
>> temp = creator()
>>   File "C:\emscripten\emscripten.py", line 2557, in ensure_struct_info
>> gen_struct_info.main(['-qo', out, path_from_root('src',
>> 'struct_info.json')])
>>   File "C:\emscripten\tools\gen_struct_info.py", line 529, in main
>> struct_info = inspect_code(header_files, cpp_opts, structs, defines)
>>   File "C:\emscripten\tools\gen_struct_info.py", line 407, in inspect_code
>> info = shared.run_js(js_file[1]).splitlines()
>>   File "C:\emscripten\tools\shared.py", line 1090, in run_js
>> return jsrun.run_js(filename, engine, *args, **kw)
>>   File "C:\emscripten\tools\jsrun.py", line 155, in run_js
>> raise Exception('Expected the command ' + str(command) + ' to finish
>> with return code ' + str(assert_returncode) + ', but it returned with code
>> ' + str(proc.returncode) + ' instead! Output: ' + str(ret)[:error_limit])
>> Exception: Expected the command ['C:\\Program Files\\nodejs\\node.exe',
>> 'c:\\users\\osman\\appdata\\local\\temp\\tmpadbhvx.js'] to finish with
>> return code 0, but it returned with code -1073741819 instead! Output:
>
>
> (The Node output from above is empty, by the way).
>
> The command I ran was:
>
> emcc -std=c11 -Wall -pedantic main.c -Os -s WASM=1 -s SIDE_MODULE=1 -s
>> BINARYEN_ASYNC_COMPILATION=0 -o main.wasm
>
>
>
> And it gave me a .wasm file -- but the file is corrupted.  When I tried to
> click "Show WebAssembly" in the context menu that comes up when
> right-clicking on a .wasm file in Visual Studio Code's left pane, I had
> these two errors:
>
> Unable to open 'main.wasm': resource is not available.
>
>
>
> and
>
> readWasm failed: 07b: error: invalid linking metadata version: 2
>
>
>
> Any help or advice is greatly appreciated.  Thanks in advance.
>
> 
>
> Anyway, yeah, I do have Emscripten; I just want to use the Wasm Backend
> with it instead of Fastcomp.
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/1320184f-e7d6-451f-8280-63a6e9742859%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EX72mPRj0KWurFCwzh_TmWRRzU3bNMzyCqz7O%2B%2BSSe6xA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using LLVM Directly to Generate WebAssembly Module (vanilla LLVM targeting WebAssembly)?

['Thomas Lively' via emscripten-discuss]

Hi Osman,

Your clang cannot find stdio.h because it does come with a C standard
library. As part of using bare clang/lld you will have to roll your own
toolchain including standard libraries. Even if you did that, in order to
use stdio.h you would have to implement emulated POSIX I/O syscalls, which
would not be trivial to get right.

Building your own installation of Emscripten is rather complex, as you have
discovered. Why don't you use the emsdk to install emscripten instead?
https://emscripten.org/docs/getting_started/downloads.htm

*From: *Osman Zakir 
*Date: *Thu, May 9, 2019 at 7:29 AM
*To: *emscripten-discuss

I'll also add this here: I did try what's shown here
> .  It
> didn't work; I got an error saying that it can't find stdio.h.  I can
> generate regular .exe files with Clang just fine, though.
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/cd408530-4e23-4912-9841-f40b1baf096f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EUPQu0HkRmpbZBu0N%2B8%2BoxcHgnKsuuoDNd7FdQv4de%2Bkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with SIMD emulation (LLVM ERROR: Unsupported integer vector type with numElems: 2, primitiveSize: 64!)

['Thomas Lively' via emscripten-discuss]

Yes, the SSE headers were removed from emscripten because they could not
actually increase performance, so it was nearly always a bad idea to be
using them. No JS engine in use today supports SIMD.js natively and
polyfilling SIMD code is slower than simply recompiling an application to
not use SIMD in the first place. In other words, using a SIMD-optimized
library with emscripten will actually be slower than using a library that
is not SIMD-optimized (or at least a non-SIMD build of the same library).

WebAssembly SIMD will of course fix this so that using SIMD can have
performance benefits. Emscripten actually does support WebAssembly SIMD
when using the LLVM backend, but it is very bleeding edge and there are
still a few bugs. And because the WebAssembly SIMD proposal is still in an
early stage, the instructions it contains are subject to change.

As for the error you are seeing, it is telling you that Fastcomp does not
support 2 x i64 vectors. Unfortunately Fastcomp does not know how to lower
unsupported vector types into supported vector types, although the LLVM
backend does. Until SIMD stabilizes in the LLVM backend and ships on JS
engines, the best way around this error is going to be to remove all uses
of 2 x i64 vectors (and 2 x f64 vectors) from your code.

On Wed, Apr 17, 2019 at 8:27 AM Flix  wrote:

> Hi everybody,
> I using emscripten version 1.38.30.
>
> I've noticed that the SIMD headers are missing from that distributions
> (and beside that, WebAssembly SIMD is probably not working with emscripten).
>
> I wanted to compile the demo in the: https://github.com/rasmusbarr/nudge
> using emscripten, and since it requires SIMD, I'm using this library:
> https://github.com/nemequ/simde to emulate it (you can read further info
> about the steps I took at the end of this thread:
> https://github.com/nemequ/simde/issues/37).
>
> Result: using desktop gcc the program compiles and run correctly in
> SIMD-emulated mode, but emscripten still outputs:
>
>> Enter code here.LLVM ERROR: Unsupported integer vector type with
>> numElems: 2, primitiveSize: 64!
>>
>
> Any idea why this happens ?
> Thank you in advance.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: GitHub org?

['Thomas Lively' via emscripten-discuss]

I like emscripten-core fine as an org name, and I think it makes sense to
do a GitHub org migration now without ruling out exploring a bigger move to
GitLab or elsewhere in the future, time allowing.

On Sun, Jan 13, 2019 at 9:36 AM Robert Aboukhalil <
robert.aboukha...@gmail.com> wrote:

> Yeah, makes sense.
>
> On Sunday, January 13, 2019 at 9:07:25 AM UTC-8, Alon Zakai wrote:
>>
>> > Random thought: have you considered having emscripten as a repo under
>> https://github.com/WebAssembly like binaryen?
>>
>> Interesting idea. Probably not an option, though, there has actually been
>> discussion about moving binaryen and wabt *out* of WebAssembly/, to keep
>> that org focused on the spec and reference implementations, and not to
>> contain miscellaneous toolchain projects (but it looks like they will stay
>> there for now). Furthermore, it might be odd to have WebAssembly/emscripten
>> and emscripten-ports/$PORT. It's more "regular" to have
>> emscripten-core/emscripten and emscripten-ports/$PORT, I think.
>>
>> On Sun, Jan 13, 2019 at 8:33 AM Robert Aboukhalil 
>> wrote:
>>
>>> Random thought: have you considered having emscripten as a repo under
>>> https://github.com/WebAssembly like binaryen?
>>>
>>>
>>> On Saturday, January 12, 2019 at 2:34:25 PM UTC-8, Alon Zakai wrote:

 > It seems to me it's time to send a message to GitHub support.  (I
 did, and sent them this thread.)

 Thanks -  maybe that will help get something done. Let's give this a
 few more days into next week to see.

 I want to stress something I said earlier, though - I think moving our
 repos from private accounts to emscripten-core solves an immediate problem
 (emscripten-core/emscripten is definitely better than kripken/emscripten,
 etc.), and should take little work and have few downsides (we need to
 update some docs, but links should be forwarded automatically etc.). So I
 think we can consider that separately from a potential move from github to
 gitlab. While that bigger move would give us gitlab.com/emscripten
 (which I created now), we'd also need someone with time to plan, evaluate,
 and execute that migration. That could only be done in the long term since
 none of the core devs have time for this atm (too much other stuff to do!
 migrate our buildbots, work on features like threads, simd, etc.), and it
 would take a long community process to decide about anyhow.

 So I think we should definitely do a quick repo transfer inside github
 soon (late next week, say). But I don't want that to discourage discussion
 about gitlab, I'm open to the idea and see the appeal. Of course one big
 migration might be less work than one small one and one big one later,
 which could be an argument for postponing the little one, but aside from
 the small one taking very little effort I am also hoping to learn from it
 about the costs of a larger migration, I'm sure unexpected stuff will come
 up.

 - Alon


 On Fri, Jan 11, 2019 at 6:37 PM Hostile Fork 
 wrote:

> Yeah, overall I see the appeal of gitlab in this context.
>>
>> However, I think we need to consider future contributors and
>> non-developer users, people that probably aren't here for the discussion.
>>
>
> Having spent time with emscripten, I don't think there's too much risk
> of the technical barrier to users being whether it's on GitHub or GitLab.
> :-)
>
> You mention there's a lot of work to do.  So I'll just reiterate the
> point: "If GitHub can't do this for you, what *can* they do?"
>
> Jason points out Haskell (GHC), and their testimonials.  If Haskell
> can do it, and have a positive experience, I'd imagine you can.
>
> It seems to me it's time to send a message to GitHub support.  (I did,
> and sent them this thread.)  If they can't steer their ship to where they
> give big projects the time of day and facilitate them, it's time to stop
> letting inertia win, and work with someone who cares.
>
> --Brian
> http://hostilefork.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to emscripten-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop 

Re: mvp-features

['Thomas Lively' via emscripten-discuss]

Hi,

Your first issue is due to an out of date Binaryen. The --mvp-features flag
was introduced upstream on December 12. I'm not sure about your second
problem, but perhaps it is related.

On Mon, Jan 14, 2019 at 2:32 AM Александр Гурьянов 
wrote:

> For bigger project, in EMCC_DEBUG=1 mode (only in debug mode) I had this
> error:
> ```
> emscripten:DEBUG: Cache: PID 16723 released multiprocess file lock to
> Emscripten cache at /home/caiiiycuk/.emscripten_cache/asmjs
> Traceback (most recent call last):
>   File "/home/caiiiycuk/emscripten/sdk/emscripten/emcc.py", line 3075,
> in 
> sys.exit(run())
>   File "/home/caiiiycuk/emscripten/sdk/emscripten/emcc.py", line 2050, in
> run
> optimizer.flush()
>   File "/home/caiiiycuk/emscripten/sdk/emscripten/emcc.py", line 280, in
> flush
> just_concat='emitJSON' in chunk)
>   File "/home/caiiiycuk/emscripten/sdk/emscripten/emcc.py", line 310,
> in run_passes
> output_filename=self.in_temp(os.path.basename(final) + '.jsopted.js'))
>   File "/home/caiiiycuk/emscripten/sdk/emscripten/tools/shared.py",
> line 2334, in js_optimizer
> ret = js_optimizer.run(filename, passes, NODE_JS, debug,
> extra_info, just_split, just_concat)
>   File "/home/caiiiycuk/emscripten/sdk/emscripten/tools/js_optimizer.py",
> line 577, in run
> return temp_files.run_and_clean(lambda: run_on_js(filename,
> passes, js_engine, source_map, extra_info, just_split, just_concat))
>   File "/home/caiiiycuk/emscripten/sdk/emscripten/tools/tempfiles.py",
> line 100, in run_and_clean
> return func()
>   File "/home/caiiiycuk/emscripten/sdk/emscripten/tools/js_optimizer.py",
> line 577, in 
> return temp_files.run_and_clean(lambda: run_on_js(filename,
> passes, js_engine, source_map, extra_info, just_split, just_concat))
>   File "/home/caiiiycuk/emscripten/sdk/emscripten/tools/js_optimizer.py",
> line 470, in run_on_js
> filenames = pool.map(run_on_chunk, commands, chunksize=1)
> TypeError: map() got an unexpected keyword argument 'chunksize'
> ninja: build stopped: subcommand failed.
> ```
>
> пн, 14 янв. 2019 г. в 17:30, Александр Гурьянов :
> >
> > Hi! What is '--mvp-features'? After updating to latest version
> > (1.38.23/incoming, and
> > binaryen/master:5b5789495a97602869f18d552b2a9e1814edefae) I can't
> > compile anything:
> >
> > main.cpp:
> > int main() {
> >   return 0;
> > }
> >
> > --
> > ~/emscripten/sdk/emscripten/emcc -Oz main.cpp -o main.html
> > Unknown option '--mvp-features'
> > shared:ERROR: '/home/caiiiycuk/emscripten/sdk/binaryen/bin/asm2wasm
> > main.temp.asm.js --total-memory=16777216 --trap-mode=allow -Oz
> > --wasm-only -o main.wasm --mvp-features' failed (1)
> >
> > --
> > EMCC_DEBUG=1 ~/emscripten/sdk/emscripten/emcc -Oz main.cpp -o main.html
> > shared:DEBUG: EM_CONFIG is located in /home/caiiiycuk/.emscripten
> > shared:DEBUG: TEMP_DIR not defined in /home/caiiiycuk/.emscripten, using
> /tmp
> > shared:DEBUG: PYTHON not defined in /home/caiiiycuk/.emscripten, using
> > "/usr/bin/python"
> > emscripten:DEBUG: Cache: PID 23323 acquiring multiprocess file lock to
> > Emscripten cache at /home/caiiiycuk/.emscripten_cache
> > emscripten:DEBUG: Cache: done
> > emscripten:DEBUG: Cache: PID 23323 released multiprocess file lock to
> > Emscripten cache at /home/caiiiycuk/.emscripten_cache
> > shared:DEBUG: check tells us to use asm.js backend
> > emcc:WARNING: invocation:
> > /home/caiiiycuk/emscripten/sdk/emscripten/emcc.py -Oz main.cpp -o
> > main.html  (in /home/caiiiycuk/emscripten/sandbox)
> > shared:DEBUG: Successfully executed
> > /home/caiiiycuk/emscripten/sdk/emscripten-fastcomp/build/bin/clang++
> > --version
> > root:DEBUG: Checking JS engine ['/usr/bin/nodejs']
> > shared:INFO: (Emscripten: Running sanity checks)
> > emcc:DEBUG: asm.js opts not forced by user or an option that depends
> > them, and we do not intend to run the asm.js, so disabling and leaving
> > opts to the binaryen optimizer
> > emcc:DEBUG: compiling to bitcode
> > emcc:DEBUG: emcc step "parse arguments and setup" took 0.54 seconds
> > emscripten:DEBUG: Cache: PID 23323 acquiring multiprocess file lock to
> > Emscripten cache at /home/caiiiycuk/.emscripten_cache/asmjs
> > emscripten:DEBUG: Cache: done
> > emcc:DEBUG: compiling source file: main.cpp
> > emcc:DEBUG: running:
> > /home/caiiiycuk/emscripten/sdk/emscripten-fastcomp/build/bin/clang++
> > -target asmjs-unknown-emscripten -D__EMSCRIPTEN_major__=1
> > -D__EMSCRIPTEN_minor__=38 -D__EMSCRIPTEN_tiny__=23
> > -D_LIBCPP_ABI_VERSION=2 -Werror=implicit-function-declaration
> > -nostdinc -Xclang -nobuiltininc -Xclang -nostdsysteminc -Xclang
> > -isystem/home/caiiiycuk/emscripten/sdk/emscripten/system/include/libcxx
> > -Xclang
> -isystem/home/caiiiycuk/emscripten/sdk/emscripten/system/lib/libcxxabi/include
> > -Xclang
> -isystem/home/caiiiycuk/emscripten/sdk/emscripten/system/include/compat
> > -Xclang -isystem/home/caiiiycuk/emscripten/sdk/emscripten/system/include
> > -Xclang
> 

Re: Port of Doom 3 video game (idTech 4 engine) to WebAssembly

['Thomas Lively' via emscripten-discuss]

This is super cool! 10/10 will play more when I can. It's really great
seeing the WebAssembly work paying off with such a low barrier to start
playing such a polished game.

On Thu, Jan 3, 2019 at 4:33 AM Gabriel CV 
wrote:

> Hello,
>
> Here is a port of the Doom 3 video game (idTech 4 engine) to WebAssembly
> using emscripten. This is based the dhewm3 GPL source port, and on the demo
> data of the game available for download on the web.
>
> Live demo:
> => http://continuation-labs.com/d3wasm
>
> Source code:
> => https://github.com/gabrielcuvillier/dhewm3-webassembly-port
>
> This demonstration is using the demo game data, which is roughly 400MB
> size. I removed DDS compressed textures and the last level of the demo to
> shrink things down a little bit. But initial loading will be QUITE long,
> depending on your bandwidth. Game data files are fetched at initial startup
> and stored persistently for cache reuse.
>
> Things seems to work correctly on several platforms/browsers I tested. The
> game is playable on modern browsers. It is even working on mobile Android,
> though not playable due to lack of controls and really bad performance :)
>
> On my system, the Game runs at 20/40 FPS on Chrome, 10/30 FPS on Firefox
> (don't know why such slower than Chrome), and 1/2 FPS on my mid-class
> Android mobile phone ;) Note that the native build shows a constant 60 FPS,
> but it is not using any GL emulation layer!
>
> A few notes:
> - Don't expect to have graphics as shiny as the native build, because the
> port is not using the "shaders" renderer path (using legacy ARB assembly
> shaders and not GLSL, this is not supported by WebGL), but instead it uses
> the fixed function pipeline renderer path that was intended for graphic
> cards without shader support at the time. It does look nice though, with
> bumpmapping/reflections & co..
>
> - Some visual glitches though (weird looking specular lights on
> characters), but they are due to the renderer path used and not because of
> underlying GL emulation library. The issue is the same with a native build
> without shader support. However, I had to disable some code in Fog
> rendering because of issues. As so, Fog is now only partially rendered, and
> sometime glitchy (you may disable it with "r_skipFogLights 1).
>
> - Loading of levels will "hangs" the display. This is due to the way
> emscripten works with "main loop based" applications, this model does not
> support well a loop iteration that last for too long (such as loading a
> level).
>
> - Under the hood, I use the Regal GL emulation layer library, with quite a
> few tweaks here and then for things to work.
> The fixed function pipeline path used by idTech 4 engine use many of the
> latest enhancements done to OpenGL before the advent of Shaders (GL 1.4 and
> co, with Texture combiners, DOT3 bumpmapping, Anisotropy, etc.). As so,
> Regal is doing a great job to emulate fixed function pipeline.
>
> - Like the previous port I did for Arx Fatalis, I had to disable
> multithreading from the game code, because it is still difficult to make
> this work with emscripten.
>
> - I did some tests to enable SIMD/SSE2 code path of the engine, but I
> discovered it is only supported in asm.js and not in wasm. Too bad!
>
> - I still need to update the README file to explain things a little bit
> more, including how to build the project (not yet 100% straightforward) and
> package the data.
>
>
> Feedback / comments welcomed
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: ETA for SIMD support in WebAssembly?

['Thomas Lively' via emscripten-discuss]

I'm the one working on toolchain support for SIMD right now. The plan is to
add builtin functions to clang for SIMD instructions that are not already
covered by clang's target-independent language extension for vectors. A
list of wasm SIMD instructions and their planned corresponding constructs
at the C level can be found here
.
Everything on that list that does not require a __builtin_wasm_* function
except vector conversions should already work with tip of tree LLVM. As far
as header files go, some other people are working on implementing
xmmintrin.h in terms of the planned builtin functions, but I don't know of
any concrete plans to port emscripten's vector.h to use them. Fortunately,
it should be straightforward to do so once the builtins exist. Many
functions in vector.h are defined inline and just use clang's vector
extensions, and those functions should also already work.

It bears mentioning the by "working" I mean the toolchain will hopefully
generate code without crashing. Whether that code actually runs in any
engine is another story. I would be very interested in hearing how far you
get if you play around with it!

On Wed, Sep 19, 2018 at 1:14 PM Soeren Balko  wrote:

> Thanks, Alon! Will this be based on the same intrinsics that Emscripten
> currently defines in vector.h (for the now deprecated SIMD.js API)?
> Background is that we want to start playing around with it asap.
>
> Soeren
>
> On Thursday, September 20, 2018 at 3:41:07 AM UTC+10, Alon Zakai wrote:
>>
>> Work is underway on the LLVM parts right now (the main blocker), and
>> making fast progress, but there is no specific ETA AFAIK. I hope it won't
>> be long though as I agree this is an important feature.
>>
>> - Alon
>>
>>
>> On Tue, Sep 18, 2018 at 8:49 PM Soeren Balko  wrote:
>>
>>> Google's weird deprecation announcement for PNaCl is making me nervous.
>>> So far, WebAssembly still lags PNaCl by a lot and the lack of SIMD support
>>> is part of the problem. Browser makers are seemingly working on this
>>> feature - but what about Emscripten? Any plans or even an ETA for when this
>>> will become available?
>>>
>>> Thanks!
>>> Soeren
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "emscripten-discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to emscripten-discuss+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to emscripten-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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