text: // Copyright 2010 The Emscripten Authors.  All rights reserved.
  // Emscripten is available under two separate licenses, the MIT license and the
  // University of Illinois/NCSA Open Source License.  Both these licenses can be
  // found in the LICENSE file.
  
  //
  // Various compiler settings. These are simply variables present when the
  // JS compiler runs. To set them, do something like:
  //
  //   emcc -s OPTION1=VALUE1 -s OPTION2=VALUE2 [..other stuff..]
  //
  // For convenience and readability `-s OPTION` expands to `-s OPTION=1`
  // and `-s NO_OPTION` expands to `-s OPTION=0` (assuming OPTION is a valid
  // option).
  //
  // See https://github.com/emscripten-core/emscripten/wiki/Code-Generation-Modes/
  //
  // Note that the values here are the defaults in -O0, that is, unoptimized
  // mode. See apply_opt_level in tools/shared.py for how -O1,2,3 affect these
  // flags.
  //
  // These flags should only have an effect when compiling to JS, so there
  // should not be a need to have them when just compiling source to
  // bitcode. However, there will also be no harm either, so it is ok to.
  //
  // Settings in this file can be directly set from the command line.  Internal
  // settings that are not part of the user ABI live in the settings_internal.js.
  //
  // In general it is best to pass the same arguments at both compile and link
  // time, as whether wasm object files are used or not affects when codegen
  // happens (without wasm object files, or when using fastcomp, codegen is all
  // during link; otherwise, it is during compile). Flags affecting codegen must
  // be passed when codegen happens, so to let a build easily switch when codegen
  // happens (LTO vs normal), pass the flags at both times. The flags are also
  // annotated in this file:
  //
  // [link] - Should be passed at link time. This is the case for all JS flags,
  //          as we emit JS at link (and that is most of the flags here, and
  //          hence the default).
  // [compile+link] - A flag that has an effect at both compile and link time,
  //                  basically any time emcc is invoked. The same flag should be
  //                  passed at both times in most cases.
  //
  // If not otherwise specified, a flag is [link]. Note that no flag is only
  // relevant during compile time, as during link we may do codegen for system
  // libraries and other support code, so all flags are either link or
  // compile+link.
  //
  // The [fastcomp-only] annotation means that a flag only affects code generation
  // in fastcomp.
  //
  
  // Tuning
  
  // Whether we should add runtime assertions, for example to
  // check that each allocation to the stack does not
  // exceed its size, whether all allocations (stack and static) are
  // of positive size, etc., whether we should throw if we encounter a bad __label__, i.e.,
  // if code flow runs into a fault
  // ASSERTIONS == 2 gives even more runtime checks
  var ASSERTIONS = 1;
  
  // Whether extra logging should be enabled.
  // This logging isn't quite assertion-quality in that it isn't necessarily a
  // symptom that something is wrong.
  var RUNTIME_LOGGING = 0;
  
  // Chooses what kind of stack smash checks to emit to generated code:
  // 0: Stack overflows are not checked.
  // 1: Adds a security cookie at the top of the stack, which is checked at end of
  //    each tick and at exit (practically zero performance overhead)
  // 2: Same as above, but also adds an explicit check for allocate() calls which
  //    call ALLOC_STACK. Has a small performance cost.
  //    -s ASSERTIONS=1 automatically enables -s STACK_OVERFLOW_CHECK=2.
  var STACK_OVERFLOW_CHECK = 0;
  
  // When set to 1, will generate more verbose output during compilation.
  var VERBOSE = 0;
  
  // Whether we will run the main() function. Disable if you embed the generated
  // code in your own, and will call main() yourself at the right time (which you
  // can do with Module.callMain(), with an optional parameter of commandline args).
  var INVOKE_RUN = 1;
  
  // If 0, the runtime is not quit when main() completes (allowing code to
  // run afterwards, for example from the browser main event loop). atexit()s
  // are also not executed, and we can avoid including code for runtime shutdown,
  // like flushing the stdio streams.
  // Set this to 1 if you do want atexit()s or stdio streams to be flushed
  // on exit.
  var EXIT_RUNTIME = 0;
  
  // How to represent the initial memory content.
  // 0: embed a base64 string literal representing the initial memory data
  // 1: create a *.mem file containing the binary data of the initial memory;
  
  //    use the --memory-init-file command line switch to select this method
  // 2: embed a string literal representing that initial memory data
  var MEM_INIT_METHOD = 0;
  
  // The total stack size. There is no way to enlarge the stack, so this
  // value must be large enough for the program's requirements. If
  // assertions are on, we will assert on not exceeding this, otherwise,
  // it will fail silently.
  var TOTAL_STACK = 5*1024*1024;
  
  // What malloc()/free() to use, out of
  //  * dlmalloc - a powerful general-purpose malloc
  //  * emmalloc - a simple and compact malloc designed for emscripten
  //  * none     - no malloc() implementation is provided, but you must implement
  //               malloc() and free() yourself.
  // dlmalloc is necessary for split memory and other special modes, and will be
  // used automatically in those cases.
  // In general, if you don't need one of those special modes, and if you don't
  // allocate very many small objects, you should use emmalloc since it's
  // smaller. Otherwise, if you do allocate many small objects, dlmalloc
  // is usually worth the extra size.
  var MALLOC = "dlmalloc";
  
  // If 1, then when malloc would fail we abort(). This is nonstandard behavior,
  // but makes sense for the web since we have a fixed amount of memory that
  // must all be allocated up front, and so (a) failing mallocs are much more
  // likely than on other platforms, and (b) people need a way to find out
  // how big that initial allocation (INITIAL_MEMORY) must be.
  // If you set this to 0, then you get the standard malloc behavior of
  // returning NULL (0) when it fails.
  var ABORTING_MALLOC = 1;
  
  // If 1, generated a version of memcpy() and memset() that unroll their
  // copy sizes. If 0, optimizes for size instead to generate a smaller memcpy.
  // This flag only has effect when targeting asm.js.
  // [fastcomp-only]
  var FAST_UNROLLED_MEMCPY_AND_MEMSET = 1;
  
  // The initial amount of memory to use. Using more memory than this will
  // cause us to expand the heap, which can be costly with typed arrays:
  // we need to copy the old heap into a new one in that case.
  // If ALLOW_MEMORY_GROWTH is set, this initial amount of memory can increase
  // later; if not, then it is the final and total amount of memory.
  //
  // (This option was formerly called TOTAL_MEMORY.)
  var INITIAL_MEMORY = 16777216;
  
  // Set the maximum size of memory in the wasm module (in bytes). Without this,
  // INITIAL_MEMORY is used (as it is used for the initial value), or if memory
  // growth is enabled, the default value here (-1) is to have no limit, but you
  // can set this to set a maximum size that growth will stop at.
  //
  // This setting only matters for wasm, as in asm.js there is no place to set
  // a maximum, and only when ALLOW_MEMORY_GROWTH is set.
  //
  // (This option was formerly called WASM_MEM_MAX and BINARYEN_MEM_MAX.)
  var MAXIMUM_MEMORY = -1;
  
  // If false, we abort with an error if we try to allocate more memory than
  // we can (INITIAL_MEMORY). If true, we will grow the memory arrays at
  // runtime, seamlessly and dynamically. This has a performance cost in asm.js,
  // both during the actual growth and in general (the latter is because in
  // that case we must be careful about optimizations, in particular the
  // eliminator), but in wasm it is efficient and should be used whenever relevant.
  // See https://code.google.com/p/v8/issues/detail?id=3907 regarding
  // memory growth performance in chrome.
  // Note that growing memory means we replace the JS typed array views, as
  // once created they cannot be resized. (This happens both in asm.js and in
  // wasm - in wasm we can grow the Memory, but still need to create new
  // views for JS.)
  // Setting this option on will disable ABORTING_MALLOC, in other words,
  // ALLOW_MEMORY_GROWTH enables fully standard behavior, of both malloc
  // returning 0 when it fails, and also of being able to allocate more
  // memory from the system as necessary.
  var ALLOW_MEMORY_GROWTH = 0;
  
  // If ALLOW_MEMORY_GROWTH is true, this variable specifies the geometric
  // overgrowth rate of the heap at resize. Specify MEMORY_GROWTH_GEOMETRIC_STEP=0
  // to disable overgrowing the heap at all, or e.g.
  // MEMORY_GROWTH_GEOMETRIC_STEP=1.0 to double the heap (+100%) at every grow step.
  // The larger this value is, the more memory the WebAssembly heap overreserves
  // to reduce performance hiccups coming from memory resize, and the smaller
  // this value is, the more memory is conserved, at the performance of more
  // stuttering when the heap grows. (profiled to be on the order of ~20 msecs)
  var MEMORY_GROWTH_GEOMETRIC_STEP = 0.20;
  
  // Specifies a cap for the maximum geometric overgrowth size, in bytes. Use
  // this value to constrain the geometric grow to not exceed a specific rate.
  // Pass MEMORY_GROWTH_GEOMETRIC_CAP=0 to disable the cap and allow unbounded
  // size increases.
  var MEMORY_GROWTH_GEOMETRIC_CAP = 96*1024*1024;
  
  // If ALLOW_MEMORY_GROWTH is true and MEMORY_GROWTH_LINEAR_STEP == -1, then
  // geometric memory overgrowth is utilized (above variable). Set
  // MEMORY_GROWTH_LINEAR_STEP to a multiple of WASM page size (64KB), eg. 16MB to
  // replace geometric overgrowth rate with a constant growth step size. When
  // MEMORY_GROWTH_LINEAR_STEP is used, the variables MEMORY_GROWTH_GEOMETRIC_STEP
  // and MEMORY_GROWTH_GEOMETRIC_CAP are ignored.
  var MEMORY_GROWTH_LINEAR_STEP = -1;
  
  // If true, allows more functions to be added to the table at runtime. This is
  // necessary for dynamic linking, and set automatically in that mode.
  var ALLOW_TABLE_GROWTH = 0;
  
  // where global data begins; the start of static memory. -1 means use the
  // default, any other value will be used as an override
  var GLOBAL_BASE = -1;
  
  // where the stack will begin. -1 means use the default. if the stack cannot
  // start at the value specified here, it may start at a higher location.
  // this is useful when debugging two builds that may differ in their static
  // allocations, by forcing the stack to start in the same place their
  // memory usage patterns would be the same.
  
  // How to load and store 64-bit doubles.  A potential risk is that doubles may
  // be only 32-bit aligned. Forcing 64-bit alignment in Clang itself should be
  // able to solve that, or as a workaround in DOUBLE_MODE 1 we will carefully
  // load in parts, in a way that requires only 32-bit alignment. In DOUBLE_MODE 0
  // we will simply store and load doubles as 32-bit floats, so when they are
  // stored/loaded they will truncate from 64 to 32 bits, and lose precision. This
  // is faster, and might work for some code (but probably that code should just
  // use floats and not doubles anyhow).  Note that a downside of DOUBLE_MODE 1 is
  // that we currently store the double in parts, then load it aligned, and that
  // load-store will make JS engines alter it if it is being stored to a typed
  // array for security reasons. That will 'fix' the number from being a NaN or an
  // infinite number.
  // [fastcomp-only]
  var DOUBLE_MODE = 1;
  
  // Warn at compile time about instructions that LLVM tells us are not fully
  // aligned.  This is useful to find places in your code where you might refactor
  // to ensure proper alignment.  This is currently only supported in asm.js, not
  // wasm.
  var WARN_UNALIGNED = 0;
  
  // 0: Use JS numbers for floating-point values. These are 64-bit and do not model C++
  //    floats exactly, which are 32-bit.
  // 1: Model C++ floats precisely, using Math.fround, polyfilling when necessary. This
  //    can be slow if the polyfill is used on heavy float32 computation. See note on
  //    browser support below.
  // 2: Model C++ floats precisely using Math.fround if available in the JS engine, otherwise
  //    use an empty polyfill. This will have much less of a speed penalty than using the full
  //    polyfill in cases where engine support is not present. In addition, we can
  //    remove the empty polyfill calls themselves on the client when generating html,
  //    which should mean that this gives you the best of both worlds of 0 and 1, and is
  //    therefore recommended, *unless* you need a guarantee of proper float32 precision
  //    (in that case, use option 1).
  // XXX Note: To optimize float32-using code, we use the 'const' keyword in the emitted
  //           code. This allows us to avoid unnecessary calls to Math.fround, which would
  //           slow down engines not yet supporting that function. 'const' is present in
  //           all modern browsers, including Firefox, Chrome and Safari, but in IE is only
  //           present in IE11 and above. Therefore if you need to support legacy versions of
  //           IE, you should not enable PRECISE_F32 1 or 2.
  // [fastcomp-only]
  // With upstream backend and WASM=0, JS output always uses Math.fround for consistent
  // behavior with WebAssembly.
  var PRECISE_F32 = 0;
  
  // Whether to allow autovectorized SIMD code
  // (https://github.com/johnmccutchan/ecmascript_simd).  SIMD intrinsics are
  // always compiled to SIMD code, so you only need this option if you also want
  // the autovectorizer to run.  Note that SIMD support in browsers is not yet
  // there (as of Sep 2, 2014), so you will be running in a polyfill, which is not
  // fast.
  var SIMD = 0;
  
  // Whether closure compiling is being run on this output
  var USE_CLOSURE_COMPILER = 0;
  
  // Specifies how warnings emitted by Closure are treated. Possible
  // options: 'quiet', 'warn', 'error'. If set to 'warn', Closure warnings are printed
  // out to console. If set to 'error', Closure warnings are treated like errors,
  // similar to -Werror compiler flag.
  var CLOSURE_WARNINGS = 'quiet';
  
  // If set to 1, each asm.js/wasm module export is individually declared with a
  // JavaScript "var" definition. This is the simple and recommended approach.
  // However, this does increase code size (especially if you have many such
  // exports), which can be avoided in an unsafe way by setting this to 0. In that
  // case, no "var" is created for each export, and instead a loop (of small
  // constant code size, no matter how many exports you have) writes all the
  // exports received into the global scope. Doing so is dangerous since such
  // modifications of the global scope can confuse external JS minifier tools, and
  // also things can break if the scope the code is in is not the global scope
  // (e.g. if you manually enclose them in a function scope).
  var DECLARE_ASM_MODULE_EXPORTS = 1;
  
  // Ignore closure warnings and errors (like on duplicate definitions)
  var IGNORE_CLOSURE_COMPILER_ERRORS = 0;
  
  // A limit on inlining. If 0, we will inline normally in LLVM and closure. If
  // greater than 0, we will *not* inline in LLVM, and we will prevent inlining of
  // functions of this size or larger in closure. 50 is a reasonable setting if
  // you do not want inlining
  // [compile+link]
  var INLINING_LIMIT = 0;
  
  // Run aggressiveVariableElimination in js-optimizer.js
  // [fastcomp-only]
  var AGGRESSIVE_VARIABLE_ELIMINATION = 0;
  
  // Whether to simplify ifs in js-optimizer.js
  // [fastcomp-only]
  var SIMPLIFY_IFS = 1;
  
  // Check each write to the heap, for example, this will give a clear
  // error on what would be segfaults in a native build (like dereferencing
  // 0). See preamble.js for the actual checks performed.
  var SAFE_HEAP = 0;
  
  // Log out all SAFE_HEAP operations
  var SAFE_HEAP_LOG = 0;
  
  // In asm.js mode, we cannot simply add function pointers to function tables, so
  // we reserve some slots for them. An alternative to this is to use
  // EMULATED_FUNCTION_POINTERS, in which case we don't need to reserve.
  var RESERVED_FUNCTION_POINTERS = 0;
  
  // Whether to allow function pointers to alias if they have a different type.
  // This can greatly decrease table sizes in asm.js, but can break code that
  // compares function pointers across different types.
  // [fastcomp-only]
  var ALIASING_FUNCTION_POINTERS = 0;
  
  // asm.js: By default we implement function pointers using asm.js function
  // tables, which is very fast. With this option, we implement them more flexibly
  // by emulating them: we call out into JS, which handles the function tables.
  //  1: Full emulation. This means you can modify the
  //     table in JS fully dynamically, not just add to
  //     the end.
  //  2: Optimized emulation. Assumes once something is
  //     added to the table, it will not change. This allows
  //     dynamic linking while keeping performance fast,
  //     as we can do a fast call into the internal table
  //     if the fp is in the right range. Shared modules
  //     (MAIN_MODULE, SIDE_MODULE) do this by default.
  //     This requires RELOCATABLE to be set.
  // wasm:
  // By default we use a wasm Table for function pointers, which is fast and
  // efficient. When enabling emulation, we also use the Table *outside* the wasm
  // module, exactly as when emulating in asm.js, just replacing the plain JS
  // array with a Table.
  // [fastcomp-only]
  var EMULATED_FUNCTION_POINTERS = 0;
  
  // Allows function pointers to be cast, wraps each call of an incorrect type
  // with a runtime correction.  This adds overhead and should not be used
  // normally.  It also forces ALIASING_FUNCTION_POINTERS to 0.  Aside from making
  // calls not fail, this tries to convert values as best it can. In asm.js, this
  // uses doubles as the JS number type, so if you send a double to a parameter
  // accepting an int, it will be |0-d into a (signed) int. In wasm, we have i64s
  // so that is not valid, and instead we use 64 bits to represent values, as if
  // we wrote the sent value to memory and loaded the received type from the same
  // memory (using truncs/extends/ reinterprets). This means that when types do
  // not match the emulated values may differ between asm.js and wasm (and native,
  // for that matter - this is all undefined behavior). In any case, both
  // approaches appear good enough to support Python, which is the main use case
  // motivating this feature.
  var EMULATE_FUNCTION_POINTER_CASTS = 0;
  
  // Print out exceptions in emscriptened code. Does not work in asm.js mode
  var EXCEPTION_DEBUG = 0;
  
  // If 1, build in libcxxabi's full c++ demangling code, to allow stackTrace()
  // to emit fully proper demangled c++ names
  var DEMANGLE_SUPPORT = 0;
  
  // Print out when we enter a library call (library*.js). You can also unset
  // Runtime.debug at runtime for logging to cease, and can set it when you want
  // it back. A simple way to set it in C++ is
  //   emscripten_run_script("Runtime.debug = ...;");
  var LIBRARY_DEBUG = 0;
  
  // Print out all musl syscalls, including translating their numeric index
  // to the string name, which can be convenient for debugging. (Other system
  // calls are not numbered and already have clear names; use LIBRARY_DEBUG
  // to get logging for all of them.)
  var SYSCALL_DEBUG = 0;
  
  // Log out socket/network data transfer.
  var SOCKET_DEBUG = 0;
  
  // Select socket backend, either webrtc or websockets. XXX webrtc is not
  // currently tested, may be broken
  
  // As well as being configurable at compile time via the "-s" option the
  // WEBSOCKET_URL and WEBSOCKET_SUBPROTOCOL
  // settings may configured at run time via the Module object e.g.
  // Module['websocket'] = {subprotocol: 'base64, binary, text'};
  // Module['websocket'] = {url: 'wss://', subprotocol: 'base64'};
  // You can set 'subprotocol' to null, if you don't want to specify it
  // Run time configuration may be useful as it lets an application select
  // multiple different services.
  var SOCKET_WEBRTC = 0;
  
  // A string containing either a WebSocket URL prefix (ws:// or wss://) or a complete
  // RFC 6455 URL - "ws[s]:" "//" host [ ":" port ] path [ "?" query ].
  // In the (default) case of only a prefix being specified the URL will be constructed from
  // prefix + addr + ':' + port
  // where addr and port are derived from the socket connect/bind/accept calls.
  var WEBSOCKET_URL = 'ws://';
  
  // If 1, the POSIX sockets API uses a native bridge process server to proxy sockets calls
  // from browser to native world.
  var PROXY_POSIX_SOCKETS = 0;
  
  // A string containing a comma separated list of WebSocket subprotocols
  // as would be present in the Sec-WebSocket-Protocol header.
  // You can set 'null', if you don't want to specify it.
  var WEBSOCKET_SUBPROTOCOL = 'binary';
  
  // Print out debugging information from our OpenAL implementation.
  var OPENAL_DEBUG = 0;
  
  // If 1, prints out debugging related to calls from emscripten_web_socket_* functions
  // in emscripten/websocket.h.
  // If 2, additionally traces bytes communicated via the sockets.
  var WEBSOCKET_DEBUG = 0;
  
  // Adds extra checks for error situations in the GL library. Can impact
  // performance.
  var GL_ASSERTIONS = 0;
  
  // If enabled, prints out all API calls to WebGL contexts. (*very* verbose)
  var TRACE_WEBGL_CALLS = 0;
  
  // Enables more verbose debug printing of WebGL related operations. As with
  // LIBRARY_DEBUG, this is toggleable at runtime with option GL.debug.
  var GL_DEBUG = 0;
  
  // When enabled, sets preserveDrawingBuffer in the context, to allow tests to
  // work (but adds overhead)
  var GL_TESTING = 0;
  
  // How large GL emulation temp buffers are
  var GL_MAX_TEMP_BUFFER_SIZE = 2097152;
  
  // Enables some potentially-unsafe optimizations in GL emulation code
  var GL_UNSAFE_OPTS = 1;
  
  // Forces support for all GLES2 features, not just the WebGL-friendly subset.
  var FULL_ES2 = 0;
  
  // If true, glGetString() for GL_VERSION and GL_SHADING_LANGUAGE_VERSION will
  // return strings OpenGL ES format "Open GL ES ... (WebGL ...)" rather than the
  // WebGL format. If false, the direct WebGL format strings are returned. Set
  // this to true to make GL contexts appear like an OpenGL ES context in these
  // version strings (at the expense of a little bit of added code size), and to
  // false to make GL contexts appear like WebGL contexts and to save some bytes
  // from the output.
  var GL_EMULATE_GLES_VERSION_STRING_FORMAT = 1;
  
  // If true, all GL extensions are advertised in both unprefixed WebGL extension
  // format, but also in desktop/mobile GLES/GL extension format with "GL_" prefix.
  var GL_EXTENSIONS_IN_PREFIXED_FORMAT = 1;
  
  // If true, adds support for automatically enabling all GL extensions for
  // GLES/GL emulation purposes. This takes up code size. If you set this to 0,
  // you will need to manually enable the extensions you need.
  var GL_SUPPORT_AUTOMATIC_ENABLE_EXTENSIONS = 1;
  
  // If set to 0, Emscripten GLES2->WebGL translation layer does not track the kind
  // of GL errors that exist in GLES2 but do not exist in WebGL. Settings this to 0
  // saves code size. (Good to keep at 1 for development)
  var GL_TRACK_ERRORS = 1;
  
  // If true, GL contexts support the explicitSwapControl context creation flag.
  // Set to 0 to save a little bit of space on projects that do not need it.
  var GL_SUPPORT_EXPLICIT_SWAP_CONTROL = 0;
  
  // If true, calls to glUniform*fv and glUniformMatrix*fv utilize a pool of
  // preallocated temporary buffers for common small sizes to avoid generating
  // temporary garbage for WebGL 1. Disable this to optimize generated size of the
  // GL library a little bit, at the expense of generating garbage in WebGL 1. If
  // you are only using WebGL 2 and do not support WebGL 1, this is not needed and
  // you can turn it off.
  var GL_POOL_TEMP_BUFFERS = 1;
  
  // Some old Android WeChat (Chromium 37?) browser has a WebGL bug that it ignores
  // the offset of a typed array view pointing to an ArrayBuffer. Set this to
  // 1 to enable a polyfill that works around the issue when it appears. This
  // bug is only relevant to WebGL 1, the affected browsers do not support WebGL 2.
  var WORKAROUND_OLD_WEBGL_UNIFORM_UPLOAD_IGNORED_OFFSET_BUG = 0;
  
  // Deprecated. Pass -s MAX_WEBGL_VERSION=2 to target WebGL 2.0.
  var USE_WEBGL2 = 0;
  
  // Specifies the lowest WebGL version to target. Pass -s MIN_WEBGL_VERSION=1
  // to enable targeting WebGL 1, and -s MIN_WEBGL_VERSION=2 to drop support
  // for WebGL 1.0
  var MIN_WEBGL_VERSION = 1;
  
  // Specifies the highest WebGL version to target. Pass -s MAX_WEBGL_VERSION=2
  // to enable targeting WebGL 2. If WebGL 2 is enabled, some APIs (EGL, GLUT, SDL)
  // will default to creating a WebGL 2 context if no version is specified.
  var MAX_WEBGL_VERSION = 1;
  
  // If true, emulates some WebGL 1 features on WebGL 2 contexts, meaning that
  // applications that use WebGL 1/GLES 2 can initialize a WebGL 2/GLES3 context,
  // but still keep using WebGL1/GLES 2 functionality that no longer is supported
  // in WebGL2/GLES3. Currently this emulates GL_EXT_shader_texture_lod extension
  // in GLSLES 1.00 shaders, support for unsized internal texture formats, and the
  // GL_HALF_FLOAT_OES != GL_HALF_FLOAT mixup.
  var WEBGL2_BACKWARDS_COMPATIBILITY_EMULATION = 0;
  
  // Forces support for all GLES3 features, not just the WebGL2-friendly subset.
  // This automatically turns out FULL_ES2.
  var FULL_ES3 = 0;
  
  // Includes code to emulate various desktop GL features. Incomplete but useful
  // in some cases, see
  // http://kripken.github.io/emscripten-site/docs/porting/multimedia_and_graphics/OpenGL-support.html
  var LEGACY_GL_EMULATION = 0;
  
  // If you specified LEGACY_GL_EMULATION = 1 and only use fixed function pipeline
  // in your code, you can also set this to 1 to signal the GL emulation layer
  // that it can perform extra optimizations by knowing that the user code does
  // not use shaders at all. If LEGACY_GL_EMULATION = 0, this setting has no
  // effect.
  var GL_FFP_ONLY = 0;
  
  // If you want to create the WebGL context up front in JS code, set this to 1
  // and set Module['preinitializedWebGLContext'] to a precreated WebGL context.
  // WebGL initialization afterwards will use this GL context to render.
  var GL_PREINITIALIZED_CONTEXT = 0;
  
  // Enables support for WebGPU (via "webgpu/webgpu.h").
  var USE_WEBGPU = 0;
  
  // Enables building of stb-image, a tiny public-domain library for decoding
  // images, allowing decoding of images without using the browser's built-in
  // decoders. The benefit is that this can be done synchronously, however, it
  // will not be as fast as the browser itself.  When enabled, stb-image will be
  // used automatically from IMG_Load and IMG_Load_RW. You can also call the
  // stbi_* functions directly yourself.
  var STB_IMAGE = 0;
  
  // If WORKAROUND_IOS_9_RIGHT_SHIFT_BUG==1, work around Safari/WebKit bug in iOS 9.3.5: https://bugs.webkit.org/show_bug.cgi?id=151514 where computing "a >> b" or "a >>> b" in
  // JavaScript would erroneously output 0 when a!=0 and b==0, after suitable JIT compiler optimizations have been applied to a function at runtime (bug does not
  // occur in debug builds). Fix was landed in https://trac.webkit.org/changeset/196591/webkit on Feb 15th 2016. iOS 9.3.5 was released on August 25 2016, but
  // oddly did not have the fix. iOS Safari 10.3.3 was released on July 19 2017, that no longer has the issue. Unknown which released version between these was the
  // first to contain the fix, though notable is that iOS 9.3.5 and iOS 10.3.3 are the two consecutive "end-of-life" versions of iOS that users are likely
  // to be on, e.g. iPhone 4s, iPad 2, iPad 3, iPad Mini 1, Pod Touch 5 all had end-of-life at iOS 9.3.5 (tested to be affected),
  // and iPad 4, iPhone 5 and iPhone 5c all had end-of-life at iOS 10.3.3 (confirmed not affected).
  // If you do not care about old iOS 9 support, keep this disabled.
  var WORKAROUND_IOS_9_RIGHT_SHIFT_BUG = 0;
  
  // From Safari 8 (where WebGL was introduced to Safari) onwards, OES_texture_half_float and OES_texture_half_float_linear extensions
  // are broken and do not function correctly, when used as source textures.
  // See https://bugs.webkit.org/show_bug.cgi?id=183321, https://bugs.webkit.org/show_bug.cgi?id=169999,
  // https://stackoverflow.com/questions/54248633/cannot-create-half-float-oes-texture-from-uint16array-on-ipad
  var GL_DISABLE_HALF_FLOAT_EXTENSION_IF_BROKEN = 0;
  
  // If set, enables polyfilling for Math.clz32, Math.trunc, Math.imul, Math.fround.
  var POLYFILL_OLD_MATH_FUNCTIONS = 0;
  
  // Set this to enable compatibility emulations for old JavaScript engines. This gives you
  // the highest possible probability of the code working everywhere, even in rare old
  // browsers and shell environments. Specifically:
  //  * Add polyfilling for Math.clz32, Math.trunc, Math.imul, Math.fround. (-s POLYFILL_OLD_MATH_FUNCTIONS=1)
  //  * Work around iOS 9 right shift bug (-s WORKAROUND_IOS_9_RIGHT_SHIFT_BUG=1)
  //  * Work around old Chromium WebGL 1 bug (-s WORKAROUND_OLD_WEBGL_UNIFORM_UPLOAD_IGNORED_OFFSET_BUG=1)
  //  * Disable WebAssembly. (Must be paired with -s WASM=0)
  //  * Adjusts MIN_X_VERSION settings to 0 to include support for all browser versions.
  // You can also configure the above options individually.
  var LEGACY_VM_SUPPORT = 0;
  
  // By default, emscripten output will run on the web, in a web worker,
  // in node.js, or in a JS shell like d8, js, or jsc. You can set this option to
  // specify that the output should only run in one particular environment, which
  // must be one of
  //    'web'    - the normal web environment.
  //    'worker' - a web worker environment.
  //    'node'   - Node.js.
  //    'shell'  - a JS shell like d8, js, or jsc.
  // Or it can be a comma-separated list of them, e.g., "web,worker". If this is
  // the empty string, then all runtime environments are supported.
  // (There is also a 'pthread' environment, see shell.js, but it cannot be specified
  // manually yet TODO)
  var ENVIRONMENT = '';
  
  // Enable this to support lz4-compressed file packages. They are stored compressed in memory, and
  // decompressed on the fly, avoiding storing the entire decompressed data in memory at once.
  // If you run the file packager separately, you still need to build the main program with this flag,
  // and also pass --lz4 to the file packager.
  // (You can also manually compress one on the client, using LZ4.loadPackage(), but that is less
  // recommended.)
  // Limitations:
  //   * LZ4-compressed files are only decompressed when needed, so they are not available
  //     for special preloading operations like pre-decoding of images using browser codecs,
  //     preloadPlugin stuff, etc.
  //   * LZ4 files are read-only.
  var LZ4 = 0;
  
  // Disables generating code to actually catch exceptions. This disabling is on
  // by default as the overhead of exceptions is quite high in size and speed
  // currently (in the future, wasm should improve that). When exceptions are
  // disabled, if an exception actually happens then it will not be caught
  // and the program will halt (so this will not introduce silent failures).
  // There are 3 specific modes here:
  // DISABLE_EXCEPTION_CATCHING = 0 - generate code to actually catch exceptions
  // DISABLE_EXCEPTION_CATCHING = 1 - disable exception catching at all
  // DISABLE_EXCEPTION_CATCHING = 2 - disable exception catching, but enables
  //                                  catching in whitelist
  // XXX note that this removes *catching* of exceptions, which is the main
  //     issue for speed, but you should build source files with
  //     -fno-exceptions to really get rid of all exceptions code overhead,
  //     as it may contain thrown exceptions that are never caught (e.g.
  //     just using std::vector can have that). -fno-rtti may help as well.
  //
  // [compile+link] - affects user code at compile and system libraries at link
  var DISABLE_EXCEPTION_CATCHING = 1;
  
  // Enables catching exception in the listed functions only, if
  // DISABLE_EXCEPTION_CATCHING = 2 is set
  // [compile+link] - affects user code at compile and system libraries at link
  var EXCEPTION_CATCHING_WHITELIST = [];
  
  // By default we handle exit() in node, by catching the Exit exception. However,
  // this means we catch all process exceptions. If you disable this, then we no
  // longer do that, and exceptions work normally, which can be useful for libraries
  // or programs that don't need exit() to work.
  
  // Emscripten uses an ExitStatus exception to halt when exit() is called.
  // With this option, we prevent that from showing up as an unhandled
  // exception.
  var NODEJS_CATCH_EXIT = 1;
  
  // Catch unhandled rejections in node. Without this, node may print the error,
  // and that this behavior will change in future node, wait a few seconds, and
  // then exit with 0 (which hides the error if you don't read the log). With
  // this, we catch any unhandled rejection and throw an actual error, which will
  // make the process exit immediately with a non-0 return code.
  var NODEJS_CATCH_REJECTION = 1;
  
  // Whether to enable asyncify transformation
  // This allows to inject some async functions to the C code that appear to be sync
  // e.g. emscripten_sleep
  // On fastcomp this uses the Asyncify IR transform.
  // On upstream this uses the Asyncify pass in Binaryen. TODO: whitelist, coroutines
  var ASYNCIFY = 0;
  
  // The imports which can do a sync operation. If you add more you will need to
  // add them to here.
  // If the names here do not include a "module." prefix, the module is assumed
  // to be "env".
  var ASYNCIFY_IMPORTS = [
    'emscripten_sleep', 'emscripten_wget', 'emscripten_wget_data', 'emscripten_idb_load',
    'emscripten_idb_store', 'emscripten_idb_delete', 'emscripten_idb_exists',
    'emscripten_idb_load_blob', 'emscripten_idb_store_blob', 'SDL_Delay',
    'emscripten_scan_registers', 'emscripten_lazy_load_code',
    'emscripten_fiber_swap',
    'wasi_snapshot_preview1.fd_sync', '__wasi_fd_sync',
  ];
  
  // Whether indirect calls can be on the stack during an unwind/rewind.
  // If you know they cannot, then setting this can be extremely helpful, as otherwise asyncify
  // must assume an indirect call can reach almost everywhere.
  var ASYNCIFY_IGNORE_INDIRECT = 0;
  
  // The size of the asyncify stack - the region used to store unwind/rewind
  // info. This must be large enough to store the call stack and locals. If it is too
  // small, you will see a wasm trap due to executing an "unreachable" instruction.
  // In that case, you should increase this size.
  var ASYNCIFY_STACK_SIZE = 4096;
  
  // If the Asyncify blacklist is provided, then the functions in it will not
  // be instrumented even if it looks like they need to. This can be useful
  // if you know things the whole-program analysis doesn't, like if you
  // know certain indirect calls are safe and won't unwind. But if you
  // get the list wrong things will break (and in a production build user
  // input might reach code paths you missed during testing, so it's hard
  // to know you got this right), so this is not recommended unless you
  // really know what are doing, and need to optimize every bit of speed
  // and size.
  // The names in this list are names from the WebAssembly Names section. The
  // wasm backend will emit those names in *human-readable* form instead of
  // typical C++ mangling. For example, you should write Struct::func()
  // instead of _ZN6Struct4FuncEv. C is also different from C++, as C
  // names don't end with parameters; as a result foo(int) in C++ would appear
  // as just foo in C (C++ has parameters because it needs to differentiate
  // overloaded functions). You will see warnings in the console if a name in the
  // list is missing (these are not errors because inlining etc. may cause
  // changes which would mean a single list couldn't work for both -O0 and -O1
  // builds, etc.). You can inspect the wasm binary to look for the actual names,
  // either directly or using wasm-objdump or wasm-dis, etc.
  // Simple '*' wildcard matching is supported.
  var ASYNCIFY_BLACKLIST = [];
  
  // If the Asyncify whitelist is provided, then *only* the functions in the list
  // will be instrumented. Like the blacklist, getting this wrong will break
  // your application.
  // See notes on ASYNCIFY_BLACKLIST about the names.
  var ASYNCIFY_WHITELIST = [];
  
  // Allows lazy code loading: where emscripten_lazy_load_code() is written, we
  // will pause execution, load the rest of the code, and then resume.
  var ASYNCIFY_LAZY_LOAD_CODE = 0;
  
  // Runtime debug logging from asyncify internals.
  var ASYNCIFY_DEBUG = 0;
  
  // Runtime elements that are exported on Module by default. We used to export
  // quite a lot here, but have removed them all, so this option is redundant
  // given that EXTRA_EXPORTED_RUNTIME_METHODS exists, and so this option exists
  // only for backwards compatibility. You should use
  // EXTRA_EXPORTED_RUNTIME_METHODS for things you want to export from the
  // runtime.  Note that methods on this list are only exported if they are
  // included (either automatically from linking, or due to being in
  // DEFAULT_LIBRARY_FUNCS_TO_INCLUDE).
  // Note that the name may be slightly misleading, as this is for any JS library
  // element, and not just methods. For example, we can export the FS object by
  // having "FS" in this list.
  var EXPORTED_RUNTIME_METHODS = [];
  
  // Additional methods to those in EXPORTED_RUNTIME_METHODS. Adjusting that list
  // lets you remove methods that would be exported by default; setting values in
  // this list lets you add to the default list without modifying it.
  var EXTRA_EXPORTED_RUNTIME_METHODS = [];
  
  // A list of incoming values on the Module object in JS that we care about. If
  // a value is not in this list, then we don't emit code to check if you provide
  // it on the Module object. For example, if
  // you have this:
  //
  //  var Module = {
  //    print: function(x) { console.log('print: ' + x) },
  //    preRun: [function() { console.log('pre run') }]
  //  };
  //
  // Then MODULE_JS_API must contain 'print' and 'preRun'; if it does not then
  // we may not emit code to read and use that value. In other words, this
  // option lets you set, statically at compile time, the list of which Module
  // JS values you will be providing at runtime, so the compiler can better
  // optimize.
  //
  // Setting this list to [], or at least a short and concise set of names you
  // actually use, can be very useful for reducing code size. By default the
  // list contains all the possible APIs.
  //
  // FIXME: should this just be  0  if we want everything?
  var INCOMING_MODULE_JS_API = [
    'ENVIRONMENT', 'GL_MAX_TEXTURE_IMAGE_UNITS', 'SDL_canPlayWithWebAudio',
    'SDL_numSimultaneouslyQueuedBuffers', 'INITIAL_MEMORY', 'wasmMemory', 'arguments',
    'buffer', 'canvas', 'doNotCaptureKeyboard', 'dynamicLibraries',
    'elementPointerLock', 'extraStackTrace', 'forcedAspectRatio',
    'instantiateWasm', 'keyboardListeningElementfreePreloadedMediaOnUse',
    'locateFile', 'logReadFiles', 'mainScriptUrlOrBlob', 'mem',
    'monitorRunDependencies', 'noExitRuntime', 'noInitialRun', 'onAbort',
    'onCustomMessage', 'onExit', 'onFree', 'onFullScreen', 'onMalloc',
    'onRealloc', 'onRuntimeInitialized', 'postMainLoop', 'postRun', 'preInit',
    'preMainLoop', 'preRun',
    'preinitializedWebGLContextmemoryInitializerRequest', 'preloadPlugins',
    'print', 'printErr', 'quit', 'setStatus', 'statusMessage', 'stderr',
    'stdin', 'stdout', 'thisProgram', 'wasm', 'wasmBinary', 'websocket'
  ];
  
  // If set to nonzero, the provided virtual filesystem if treated
  // case-insensitive, like Windows and macOS do. If set to 0, the VFS is
  // case-sensitive, like on Linux.
  var CASE_INSENSITIVE_FS = 0;
  
  // If set to 0, does not build in any filesystem support. Useful if you are just
  // doing pure computation, but not reading files or using any streams (including
  // fprintf, and other stdio.h things) or anything related. The one exception is
  // there is partial support for printf, and puts, hackishly.  The compiler will
  // automatically set this if it detects that syscall usage (which is static)
  // does not require a full filesystem. If you still want filesystem support, use
  // FORCE_FILESYSTEM
  var FILESYSTEM = 1;
  
  // Makes full filesystem support be included, even if statically it looks like
  // it is not used. For example, if your C code uses no files, but you include
  // some JS that does, you might need this.
  var FORCE_FILESYSTEM = 0;
  
  // Enables support for the NODERAWFS filesystem backend. This is a special
  // backend as it replaces all normal filesystem access with direct Node.js
  // operations, without the need to do `FS.mount()`, and this backend only
  // works with Node.js. The initial working directory will be same as
  // process.cwd() instead of VFS root directory.  Because this mode directly uses
  // Node.js to access the real local filesystem on your OS, the code will not
  // necessarily be portable between OSes - it will be as portable as a Node.js
  // program would be, which means that differences in how the underlying OS
  // handles permissions and errors and so forth may be noticeable.  This has
  // mostly been tested on Linux so far.
  var NODERAWFS = 0;
  
  // This saves the compiled wasm module in a file with name
  //   $WASM_BINARY_NAME.$V8_VERSION.cached
  // and loads it on subsequent runs. This caches the compiled wasm code from
  // v8 in node, which saves compiling on subsequent runs, making them start up
  // much faster.
  // The V8 version used in node is included in the cache name so that we don't
  // try to load cached code from another version, which fails silently (it seems
  // to load ok, but we do actually recompile).
  //  * This requires a somewhat recent node, but unclear what version, see
  //    https://github.com/nodejs/node/issues/18265#issuecomment-471237531
  //  * This option requires WASM_ASYNC_COMPILATION=0 (we load and save code
  //    in the sync compilation path for simplicity).
  //  * The default location of the .cached files is alongside the wasm binary,
  //    as mentioned earlier. If that is in a read-only directory, you may need
  //    to place them elsewhere. You can use the locateFile() hook to do so.
  var NODE_CODE_CACHING = 0;
  
  // Functions that are explicitly exported. These functions are kept alive
  // through LLVM dead code elimination, and also made accessible outside of the
  // generated code even after running closure compiler (on "Module").  Note the
  // necessary prefix of "_".
  //
  // Note also that this is the full list of exported functions - if you have a
  // main() function and want it to run, you must include it in this list (as
  // _main is by default in this value, and if you override it without keeping it
  // there, you are in effect removing it).
  var EXPORTED_FUNCTIONS = ['_main'];
  
  // If true, we export all the symbols that are present in JS onto the Module
  // object. This does not affect which symbols will be present - it does not
  // prevent DCE or cause anything to be included in linking. It only does
  //   Module['X'] = X;
  // for all X that end up in the JS file. This is useful to export the JS
  // library functions on Module, for things like dynamic linking.
  var EXPORT_ALL = 0;
  
  // Export all bindings generator functions (prefixed with emscripten_bind_). This
  // is necessary to use the WebIDL binder with asm.js
  var EXPORT_BINDINGS = 0;
  
  // If true, export all the functions appearing in a function table, and the
  // tables themselves.
  var EXPORT_FUNCTION_TABLES = 0;
  
  // Remembers the values of these settings, and makes them accessible
  // through Runtime.getCompilerSetting and emscripten_get_compiler_setting.
  // To see what is retained, look for compilerSettings in the generated code.
  var RETAIN_COMPILER_SETTINGS = 0;
  
  // JS library elements (C functions implemented in JS) that we include by
  // default. If you want to make sure something is included by the JS compiler,
  // add it here.  For example, if you do not use some emscripten_* C API call
  // from C, but you want to call it from JS, add it here (and in EXPORTED
  // FUNCTIONS with prefix "_", if you use closure compiler).  Note that the name
  // may be slightly misleading, as this is for any JS library element, and not
  // just functions. For example, you can include the Browser object by adding
  // "$Browser" to this list.
  var DEFAULT_LIBRARY_FUNCS_TO_INCLUDE = [
    'memcpy',
    'memset',
    'malloc',
    'free',
    'emscripten_get_heap_size', // Used by dynamicAlloc() and -s FETCH=1
  ];
  
  // This list is also used to determine auto-exporting of library dependencies
  // (i.e., functions that might be dependencies of JS library functions, that if
  // so we must export so that if they are implemented in C they will be
  // accessible, in ASM_JS mode).
  var LIBRARY_DEPS_TO_AUTOEXPORT = ['memcpy'];
  
  // Include all JS library functions instead of the sum of
  // DEFAULT_LIBRARY_FUNCS_TO_INCLUDE + any functions used by the generated code.
  // This is needed when dynamically loading (i.e. dlopen) modules that make use
  // of runtime library functions that are not used in the main module.  Note that
  // this only applies to js libraries, *not* C. You will need the main file to
  // include all needed C libraries.  For example, if a module uses malloc or new,
  // you will need to use those in the main file too to pull in malloc for use by
  // the module.
  var INCLUDE_FULL_LIBRARY = 0;
  
  // Set this to a string to override the shell file used
  var SHELL_FILE = 0;
  
  // 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.
  var RELOCATABLE = 0;
  
  // A main module is a file compiled in a way that allows us to link it to
  // a side module using emlink.py.
  //  1: Normal main module.
  //  2: DCE'd main module. We eliminate dead code normally. If a side
  //     module needs something from main, it is up to you to make sure
  //     it is kept alive.
  var MAIN_MODULE = 0;
  
  // Corresponds to MAIN_MODULE (also supports modes 1 and 2)
  var SIDE_MODULE = 0;
  
  // If this is a shared object (MAIN_MODULE == 1 || SIDE_MODULE == 1), then we
  // will link these at runtime. They must have been built with SIDE_MODULE == 1.
  var RUNTIME_LINKED_LIBS = [];
  
  // If set to 1, this is a worker library, a special kind of library that is run
  // in a worker. See emscripten.h
  var BUILD_AS_WORKER = 0;
  
  // If set to 1, we build the project into a js file that will run in a worker,
  // and generate an html file that proxies input and output to/from it.
  var PROXY_TO_WORKER = 0;
  
  // If set, the script file name the main thread loads.  Useful if your project
  // doesn't run the main emscripten- generated script immediately but does some
  // setup before
  var PROXY_TO_WORKER_FILENAME = '';
  
  // If set to 1, compiles in a small stub main() in between the real main() which
  // calls pthread_create() to run the application main() in a pthread.  This is
  // something that applications can do manually as well if they wish, this option
  // is provided as convenience.
  //
  // This proxies Module['canvas'], if present, and if OFFSCREEN_CANVAS support
  // is enabled. This has to happen because this is the only chance - this browser
  // main thread does the the only pthread_create call that happens on
  // that thread, so it's the only chance to transfer the canvas from there.
  var PROXY_TO_PTHREAD = 0;
  
  // If set to 1, this file can be linked with others, either as a shared library
  // or as the main file that calls a shared library. To enable that, we will not
  // internalize all symbols and cull the unused ones, in other words, we will not
  // remove unused functions and globals, which might be used by another module we
  // are linked with.
  //
  // MAIN_MODULE and SIDE_MODULE both imply this, so it not normally necessary
  // to set this explicitly. Note that MAIN_MODULE and SIDE_MODULE mode 2 do
  // *not* set this, so that we still do normal DCE on them, and in that case
  // you must keep relevant things alive yourself using exporting.
  var LINKABLE = 0;
  
  // Emscripten 'strict' build mode: Drop supporting any deprecated build options.
  // Set the environment variable EMCC_STRICT=1 or pass -s STRICT=1 to test that a
  // codebase builds nicely in forward compatible manner.
  // Changes enabled by this:
  //   * The C define EMSCRIPTEN is not defined (__EMSCRIPTEN__ always is, and
  //     is the correct thing to use).
  //   * STRICT_JS is enabled.
  //   * AUTO_JS_LIBRARIES is disabled.
  //   * AUTO_ARCHIVE_INDEXES is disabled.
  // [compile+link]
  var STRICT = 0;
  
  // Automatically attempt to add archive indexes at link time to archives that 
  // don't already have them.  This can heppen when GNU ar or GNU ranlib is used
  // rather than `llvm-ar` or `emar` since the former don't understand the wasm
  // object format.
  // [link]
  var AUTO_ARCHIVE_INDEXES = 1;
  
  // Add "use strict;" to generated JS
  var STRICT_JS = 0;
  
  // If set to 1, we will warn on any undefined symbols that are not resolved by
  // the library_*.js files. Note that it is common in large projects to not
  // implement everything, when you know what is not going to actually be called
  // (and don't want to mess with the existing buildsystem), and functions might
  // be implemented later on, say in --pre-js, so you may want to build with -s
  // WARN_ON_UNDEFINED_SYMBOLS=0 to disable the warnings if they annoy you.  See
  // also ERROR_ON_UNDEFINED_SYMBOLS.  Any undefined symbols that are listed in-
  // EXPORTED_FUNCTIONS will also be reported.
  var WARN_ON_UNDEFINED_SYMBOLS = 1;
  
  // If set to 1, we will give a link-time error on any undefined symbols (see
  // WARN_ON_UNDEFINED_SYMBOLS). To allow undefined symbols at link time set this
  // to 0, in which case if an undefined function is called a runtime error will
  // occur.  Any undefined symbols that are listed in EXPORTED_FUNCTIONS will also
  // be reported.
  var ERROR_ON_UNDEFINED_SYMBOLS = 1;
  
  // Use small chunk size for binary synchronous XHR's in Web Workers.  Used for
  // testing.  See test_chunked_synchronous_xhr in runner.py and library.js.
  var SMALL_XHR_CHUNKS = 0;
  
  // If 1, will include shim code that tries to 'fake' a browser environment, in
  // order to let you run a browser program (say, using SDL) in the shell.
  // Obviously nothing is rendered, but this can be useful for benchmarking and
  // debugging if actual rendering is not the issue. Note that the shim code is
  // very partial - it is hard to fake a whole browser! - so keep your
  // expectations low for this to work.
  var HEADLESS = 0;
  
  // If 1, we force Date.now(), Math.random, etc. to return deterministic results.
  // Good for comparing builds for debugging purposes (and nothing else)
  var DETERMINISTIC = 0;
  
  // By default we emit all code in a straightforward way into the output
  // .js file. That means that if you load that in a script tag in a web
  // page, it will use the global scope. With MODULARIZE set, we will instead emit
  //
  //   var EXPORT_NAME = function(Module) {
  //     Module = Module || {};
  //     // .. all the emitted code from emscripten ..
  //     return Module;
  //   };
  //
  // where EXPORT_NAME is from the option of the same name (so, by default
  // it will be var Module = ..., and so you should change EXPORT_NAME if
  // you want more than one module in the same web page).
  //
  // You can then use this by something like
  //
  //   var instance = EXPORT_NAME();
  //
  // or
  //
  //   var instance = EXPORT_NAME({ option: value, ... });
  //
  // Note the parentheses - we are calling EXPORT_NAME in order to instantiate
  // the module. (This allows, in particular, for you to create multiple
  // instantiations, etc.)
  //
  // The default .html shell file provided in MINIMAL_RUNTIME mode shows
  // an example to how the module is instantiated from within the html file.
  // The default .html shell file provided by traditional runtime mode is only
  // compatible with MODULARIZE=0 mode, so when building with traditional
  // runtime, you should provided your own html shell file to perform the
  // instantiation when building with MODULARIZE=1. (For more details, see
  // https://github.com/emscripten-core/emscripten/issues/7950)
  //
  // If you add --pre-js or --post-js files, they will be included inside
  // the module with the rest of the emitted code. That way, they can be
  // optimized together with it. (If you want something outside of the module,
  // that is, literally before or after all the code including the extra
  // MODULARIZE code, you can do that by modifying the JS yourself after
  // emscripten runs. While --pre-js and --post-js happen to do that in
  // non-modularize mode, their big feature is that they add code to be
  // optimized with the rest of the emitted code, allowing better dead code
  // elimination and minification.)
  //
  // Modularize also provides a promise-like API,
  //
  //   var instance = EXPORT_NAME().then(function(Module) { .. });
  //
  // The callback is called when it is safe to run compiled code, similar
  // to the onRuntimeInitialized callback (i.e., it waits for all
  // necessary async events). It receives the instance as a parameter,
  // for convenience.
  //
  // Note that in MODULARIZE mode we do *not* look at the global `Module`
  // object, so if you define things there they will be ignored. The reason
  // is that you will be constructing the instances manually, and can
  // provide Module there, or something else, as you want. This differs
  // in MODULARIZE_INSTANCE mode, where we *do* look at the global, since
  // as in non-MODULARIZE mode there is just one global instance, and it
  // is constructed by the setup code.
  var MODULARIZE = 0;
  
  // Similar to MODULARIZE, but while that mode exports a function, with which you
  // can create multiple instances, this option exports a singleton instance. In
  // other words, it's the same as if you used MODULARIZE and did EXPORT_NAME =
  // EXPORT_NAME() to create the instance manually.
  //
  // Note that the promise-like API MODULARIZE provides isn't available here
  // (since you aren't creating the instance yourself).
  var MODULARIZE_INSTANCE = 0;
  
  // If we separate out asm.js with the --separate-asm option,
  // this is the name of the variable where the generated asm.js
  // Module is assigned to. This name can either be a property
  // of Module, or a freestanding variable name, like "var asmJs".
  // If you are XHRing in multiple asm.js built files, use this option to
  // assign the generated asm.js modules to different variable names
  // so that they do not conflict. Default name is 'Module["asm"]' if a custom
  // name is not passed in.
  var SEPARATE_ASM_MODULE_NAME = '';
  
  // Export using an ES6 Module export rather than a UMD export.  MODULARIZE must
  // be enabled for ES6 exports.
  var EXPORT_ES6 = 0;
  
  // Use the ES6 Module relative import feature 'import.meta.url'
  // to auto-detect WASM Module path.
  // It might not be supported on old browsers / toolchains
  var USE_ES6_IMPORT_META = 1;
  
  // If 1, will just time how long main() takes to execute, and not print out
  // anything at all whatsoever. This is useful for benchmarking.
  var BENCHMARK = 0;
  
  // If 1, generate code in asm.js format. If 2, emits the same code except for
  // omitting 'use asm'.
  // [fastcomp-only]
  var ASM_JS = 1;
  
  // If 1, will finalize the final emitted code, including operations that prevent
  // later js optimizer passes from running, like converting +5 into 5.0 (the js
  // optimizer sees 5.0 as just 5).
  // [fastcomp-only]
  var FINALIZE_ASM_JS = 1;
  
  // If 1, then all exports from the asm/wasm module will be accessed indirectly,
  // which allow the module to be swapped later, simply by replacing
  // Module['asm'].
  //
  // Note: It is very important that the replacement module be built with the same
  // optimizations and so forth, as we depend on them being a drop-in replacement
  // for each other (same globals on the heap at the same locations, etc.)
  var SWAPPABLE_ASM_MODULE = 0;
  
  // see emcc --separate-asm
  // [fastcomp-only]
  var SEPARATE_ASM = 0;
  
  // JS library functions on this list are not converted to JS, and calls to them
  // are turned into abort()s. This is potentially useful for reducing code size.
  // If a dead function is actually called, you will get a runtime error.
  //
  // TODO: make this work on compiled methods as well, perhaps by adding a JS
  // optimizer pass?
  var DEAD_FUNCTIONS = [];
  
  // Global variable to export the module as for environments without a
  // standardized module loading system (e.g. the browser and SM shell).
  var EXPORT_NAME = 'Module';
  
  // When set to 0, we do not emit eval() and new Function(), which disables some functionality
  // (causing runtime errors if attempted to be used), but allows the emitted code to be
  // acceptable in places that disallow dynamic code execution (chrome packaged app,
  // privileged firefox app, etc.). Pass this flag when developing an Emscripten application
  // that is targeting a privileged or a certified execution environment, see
  // Firefox Content Security Policy (CSP) webpage for details:
  // https://developer.mozilla.org/en-US/Apps/Build/Building_apps_for_Firefox_OS/CSP
  // When this flag is set, the following features (linker flags) are unavailable:
  //  --closure 1: When using closure compiler, eval() would be needed to locate the Module object.
  //  -s RELOCATABLE=1: the function Runtime.loadDynamicLibrary would need to eval().
  //  --bind: Embind would need to eval().
  // Additionally, the following Emscripten runtime functions are unavailable when
  // DYNAMIC_EXECUTION=0 is set, and an attempt to call them will throw an exception:
  // - emscripten_run_script(),
  // - emscripten_run_script_int(),
  // - emscripten_run_script_string(),
  // - dlopen(),
  // - the functions ccall() and cwrap() are still available, but they are restricted to only
  //   being able to call functions that have been exported in the Module object in advance.
  // When set to -s DYNAMIC_EXECUTION=2 flag is set, attempts to call to eval() are demoted
  // to warnings instead of throwing an exception.
  var DYNAMIC_EXECUTION = 1;
  
  // Runs tools/emterpretify on the compiler output.
  // [fastcomp-only]
  var EMTERPRETIFY = 0;
  
  // If defined, a file to write bytecode to, otherwise the default is to embed it
  // in text JS arrays (which is less efficient).  When emitting HTML, we
  // automatically generate code to load this file and set it to
  // Module.emterpreterFile. If you emit JS, you need to make sure that
  // Module.emterpreterFile contains an ArrayBuffer with the bytecode, when the
  // code loads.  Note: You might need to quote twice in the shell, something like
  // -s 'EMTERPRETIFY_FILE="waka"'
  // [fastcomp-only]
  var EMTERPRETIFY_FILE = '';
  
  // Functions to not emterpret, that is, to run normally at full speed
  // [fastcomp-only]
  var EMTERPRETIFY_BLACKLIST = [];
  
  // If this contains any functions, then only the functions in this list are
  // emterpreted (as if all the rest are blacklisted; this overrides the
  // BLACKLIST)
  // [fastcomp-only]
  var EMTERPRETIFY_WHITELIST = [];
  
  // Allows sync code in the emterpreter, by saving the call stack, doing an async
  // delay, and resuming it
  // [fastcomp-only]
  var EMTERPRETIFY_ASYNC = 0;
  
  // Performs a static analysis to suggest which functions should be run in the
  // emterpreter, as it appears they can be on the stack when a sync function is
  // called in the EMTERPRETIFY_ASYNC option.  After showing the suggested list,
  // compilation will halt. You can apply the provided list as an emcc argument
  // when compiling later.
  // [fastcomp-only]
  var EMTERPRETIFY_ADVISE = 0;
  
  // If you have additional custom synchronous functions, add them to this list
  // and the advise mode will include them in its analysis.
  // [fastcomp-only]
  var EMTERPRETIFY_SYNCLIST = [];
  
  // whether js opts will be run, after the main compiler
  var RUNNING_JS_OPTS = 0;
  
  // whether we are in the generate struct_info bootstrap phase
  var BOOTSTRAPPING_STRUCT_INFO = 0;
  
  // struct_info that is either generated or cached
  var STRUCT_INFO = '';
  
  // Add some calls to emscripten tracing APIs
  var EMSCRIPTEN_TRACING = 0;
  
  // Specify the GLFW version that is being linked against.  Only relevant, if you
  // are linking against the GLFW library.  Valid options are 2 for GLFW2 and 3
  // for GLFW3.
  var USE_GLFW = 2;
  
  // Whether to use compile code to WebAssembly. Set this to 0 to compile to
  // asm.js in fastcomp, or JS in upstream.
  //
  // Note that in upstream, WASM=0 behaves very similarly to WASM=1, in particular
  // startup can be either async or sync, so flags like WASM_ASYNC_COMPILATION
  // still make sense there, see that option for more details.
  //
  // Specify -s WASM=2 to target both WebAssembly and JavaScript at the same time.
  // In that build mode, two files a.wasm and a.wasm.js are produced, and at runtime
  // the WebAssembly file is loaded if browser/shell supports it. Otherwise the
  // .wasm.js fallback will be used.
  var WASM = 1;
  
  // STANDALONE_WASM indicates that we want to emit a wasm file that can run without
  // JavaScript. The file will use standard APIs such as wasi as much as possible
  // to achieve that.
  //
  // This option does not guarantee that the wasm can be used by itself - if you
  // use APIs with no non-JS alternative, we will still use those (e.g., OpenGL
  // at the time of writing this). This gives you the option to see which APIs
  // are missing, and if you are compiling for a custom wasi embedding, to add
  // those to your embedding.
  //
  // We may still emit JS with this flag, but the JS should only be a convenient
  // way to run the wasm on the Web or in Node.js, and you can run the wasm by
  // itself without that JS (again, unless you use APIs for which there is no
  // non-JS alternative) in a wasm runtime like wasmer or wasmtime.
  //
  // Note that even without this option we try to use wasi etc. syscalls as much
  // as possible. What this option changes is that we do so even when it means
  // a tradeoff with JS size. For example, when this option is set we do not
  // import the Memory - importing it is useful for JS, so that JS can start to
  // use it before the wasm is even loaded, but in wasi and other wasm-only
  // environments the expectation is to create the memory in the wasm itself.
  // Doing so prevents some possible JS optimizations, so we only do it behind
  // this flag.
  var STANDALONE_WASM = 0;
  
  // Whether to use the WebAssembly backend that is in development in LLVM.  You
  // should not set this yourself, instead set EMCC_WASM_BACKEND=1 in the
  // environment.
  var WASM_BACKEND = 0;
  
  // An optional comma-separated list of script hooks to run after binaryen,
  // in binaryen's /scripts dir.
  var BINARYEN_SCRIPTS = "";
  
  // Whether to ignore implicit traps when optimizing in binaryen.  Implicit
  // traps are the traps that happen in a load that is out of bounds, or
  // div/rem of 0, etc. With this option set, the optimizer assumes that loads
  // cannot trap, and therefore that they have no side effects at all. This
  // is *not* safe in general, as you may have a load behind a condition which
  // ensures it it is safe; but if the load is assumed to not have side effects it
  // could be executed unconditionally. For that reason this option is generally
  // not useful on large and complex projects, but in a small and simple enough
  // codebase it may help reduce code size a little bit.
  var BINARYEN_IGNORE_IMPLICIT_TRAPS = 0;
  
  // How we handle wasm operations that may trap, which includes integer
  // div/rem of 0 and float-to-int of values too large to fit in an int.
  //   js: do exactly what js does. this can be slower.
  //   clamp: avoid traps by clamping to a reasonable value. this can be
  //          faster than "js".
  //   allow: allow creating operations that can trap. this is the most
  //          compact, as we just emit a single wasm operation, with no
  //          guards to trapping values, and also often the fastest.
  // [fastcomp-only]
  var BINARYEN_TRAP_MODE = "allow";
  
  // A comma-separated list of passes to run in the binaryen optimizer, for
  // example, "dce,precompute,vacuum".  When set, this overrides/replaces
  // the default passes we would normally run.
  // Note that you can put any binaryen wasm-opt flag here, not just
  // passes. The key thing is that these flags are sent to the main wasm-opt
  // invocation to optimize the wasm binary, which is when we run several
  // important passes. We may also run wasm-opt for various other reasons,
  // like as part of metadce, and these flags are not passed at those times,
  // so they are a bunch of passes (+ other flags) for that one main
  // invocation.
  var BINARYEN_PASSES = "";
  
  // A comma-separated list of passes to run in the binaryen optimizer, like
  // BINARYEN_PASSES, but that is in addition to any default ones. That is,
  // setting this does not override/replace the default passes, and it is
  // appended at the end of the list of passes.
  var BINARYEN_EXTRA_PASSES = "";
  
  // Whether to compile the wasm asynchronously, which is more efficient and does
  // not block the main thread. This is currently required for all but the
  // smallest modules to run in chrome.
  //
  // Note that this flag is still useful even if WASM=0 when using the upstream
  // backend, as startup behaves the same there as WASM=1 (the implementation is
  // of a fake WebAssembly.* object, so the startup code doesn't know it's JS
  // and not wasm). That makes it easier to swap between JS and wasm builds,
  // however, this is a difference from fastcomp in which WASM=0 always meant
  // sync startup as asm.js (unless a mem init file was used or some other thing
  // that forced async).
  //
  // (This option was formerly called BINARYEN_ASYNC_COMPILATION)
  var WASM_ASYNC_COMPILATION = 1;
  
  // WebAssembly defines a "producers section" which compilers and tools can
  // annotate themselves in. Emscripten does not emit this by default, as it
  // increases code size, and some users may not want information about their tools
  // to be included in their builds for privacy or security reasons, see
  // https://github.com/WebAssembly/tool-conventions/issues/93.
  // TODO: currently this flag just controls whether we run the binaryen pass
  //       to strip it out from the wasm (where the LLVM wasm backend may have
  //       created it)
  var EMIT_PRODUCERS_SECTION = 0;
  
  // Whether to legalize the JS FFI interfaces (imports/exports) by wrapping them
  // to automatically demote i64 to i32 and promote f32 to f64. This is necessary
  // in order to interface with JavaScript, both for asm.js and wasm.  For
  // non-web/non-JS embeddings, setting this to 0 may be desirable.
  // LEGALIZE_JS_FFI=0 is incompatible with RUNNING_JS_OPTS.
  var LEGALIZE_JS_FFI = 1;
  
  // Ports
  
  // Specify the SDL version that is being linked against.
  // 1, the default, is 1.3, which is implemented in JS
  // 2 is a port of the SDL C code on emscripten-ports
  var USE_SDL = 1;
  
  // Specify the SDL_gfx version that is being linked against. Must match USE_SDL
  var USE_SDL_GFX = 0;
  
  // Specify the SDL_image version that is being linked against. Must match USE_SDL
  var USE_SDL_IMAGE = 1;
  
  // Specify the SDL_ttf version that is being linked against. Must match USE_SDL
  var USE_SDL_TTF = 1;
  
  // Specify the SDL_net version that is being linked against. Must match USE_SDL
  var USE_SDL_NET = 1;
  
  // 1 = use icu from emscripten-ports
  var USE_ICU = 0;
  
  // 1 = use zlib from emscripten-ports
  var USE_ZLIB = 0;
  
  // 1 = use bzip2 from emscripten-ports
  var USE_BZIP2 = 0;
  
  // 1 = use libjpeg from emscripten-ports
  var USE_LIBJPEG = 0;
  
  // 1 = use libpng from emscripten-ports
  var USE_LIBPNG = 0;
  
  // 1 = use Regal from emscripten-ports
  var USE_REGAL = 0;
  
  // 1 = use Boost headers from emscripten-ports
  var USE_BOOST_HEADERS = 0;
  
  // 1 = use bullet from emscripten-ports
  var USE_BULLET = 0;
  
  // 1 = use vorbis from emscripten-ports
  var USE_VORBIS = 0;
  
  // 1 = use ogg from emscripten-ports
  var USE_OGG = 0;
  
  // 1 = use freetype from emscripten-ports
  var USE_FREETYPE = 0;
  
  // Specify the SDL_mixer version that is being linked against.
  // Doesn't *have* to match USE_SDL, but a good idea.
  var USE_SDL_MIXER = 1;
  
  // 1 = use harfbuzz from harfbuzz upstream
  var USE_HARFBUZZ = 0;
  
  // 3 = use cocos2d v3 from emscripten-ports
  var USE_COCOS2D = 0;
  
  // Formats to support in SDL2_image. Valid values: bmp, gif, lbm, pcx, png, pnm, tga, xcf, xpm, xv
  var SDL2_IMAGE_FORMATS = [];
  
  // The list of defines (C_DEFINES) was moved into struct_info.json in the same
  // directory.  That file is automatically parsed by tools/gen_struct_info.py.
  // If you modify the headers, just clear your cache and emscripten libc should
  // see the new values.
  
  // If true, the current build is performed for the Emscripten test harness.
  var IN_TEST_HARNESS = 0;
  
  // If true, enables support for pthreads.
  // [compile+link] - affects user code at compile and system libraries at link
  var USE_PTHREADS = 0;
  
  // In web browsers, Workers cannot be created while the main browser thread
  // is executing JS/Wasm code, but the main thread must regularly yield back
  // to the browser event loop for Worker initialization to occur.
  // This means that pthread_create() is essentially an asynchronous operation
  // when called from the main browser thread, and the main thread must
  // repeatedly yield back to the JS event loop in order for the thread to
  // actually start.
  // If your application needs to be able to synchronously create new threads,
  // you can pre-create a pthread pool by specifying -s PTHREAD_POOL_SIZE=x,
  // in which case the specified number of Workers will be preloaded into a pool
  // before the application starts, and that many threads can then be available
  // for synchronous creation.
  // Note that this setting is a string, and will be emitted in the JS code
  // (directly, with no extra quotes) so that if you set it to '5' then 5 workers
  // will be used in the pool, and so forth. The benefit of this being a string
  // is that you can set it to something like
  // 'navigator.hardwareConcurrency' (which will use the number of cores the
  // browser reports, and is how you can get exactly enough workers for a
  // threadpool equal to the number of cores).
  // [link] - affects generated JS runtime code at link time
  var PTHREAD_POOL_SIZE = '';
  
  // If your application does not need the ability to synchronously create
  // threads, but it would still like to opportunistically speed up initial thread
  // startup time by prewarming a pool of Workers, you can specify the size of
  // the pool with -s PTHREAD_POOL_SIZE=x, but then also specify
  // -s PTHREAD_POOL_DELAY_LOAD=1, which will cause the runtime to not wait up at
  // startup for the Worker pool to finish loading. Instead, the runtime will
  // immediately start up and the Worker pool will asynchronously spin up in
  // parallel on the background. This can shorten the time that pthread_create()
  // calls take to actually start a thread, but without actually slowing down
  // main application startup speed. If PTHREAD_POOL_DELAY_LOAD=0 (default),
  // then the runtime will wait for the pool to start up before running main().
  // [link] - affects generated JS runtime code at link time
  var PTHREAD_POOL_DELAY_LOAD = 0;
  
  // If not explicitly specified, this is the stack size to use for newly created
  // pthreads.  According to
  // http://man7.org/linux/man-pages/man3/pthread_create.3.html, default stack
  // size on Linux/x86-32 for a new thread is 2 megabytes, so follow the same
  // convention. Use pthread_attr_setstacksize() at thread creation time to
  // explicitly specify the stack size, in which case this value is ignored. Note
  // that the asm.js/wasm function call control flow stack is separate from this
  // stack, and this stack only contains certain function local variables, such as
  // those that have their addresses taken, or ones that are too large to fit as
  // local vars in asm.js/wasm code.
  var DEFAULT_PTHREAD_STACK_SIZE = 2*1024*1024;
  
  // True when building with --threadprofiler
  var PTHREADS_PROFILING = 0;
  
  // It is dangerous to call pthread_join or pthread_cond_wait
  // on the main thread, as doing so can cause deadlocks on the Web (and also
  // it works using a busy-wait which is expensive). See
  // https://emscripten.org/docs/porting/pthreads.html#blocking-on-the-main-browser-thread
  // This may become set to 0 by default in the future; for now, this just
  // warns in the console.
  var ALLOW_BLOCKING_ON_MAIN_THREAD = 1;
  
  // If true, add in debug traces for diagnosing pthreads related issues.
  var PTHREADS_DEBUG = 0;
  
  // If true, building against Emscripten's asm.js/wasm heap memory profiler.
  var MEMORYPROFILER = 0;
  
  // Duplicate function elimination. This coalesces function bodies that are
  // identical, which can happen e.g. if two methods have different C/C++ or LLVM
  // types, but end up identical at the asm.js level (all pointers are the same as
  // int32_t in asm.js, for example).
  //
  // This option is quite slow to run, as it processes and hashes all methods in
  // the codebase in multiple passes.
  //
  // [fastcomp-only]
  var ELIMINATE_DUPLICATE_FUNCTIONS = 0; // disabled by default
  var ELIMINATE_DUPLICATE_FUNCTIONS_DUMP_EQUIVALENT_FUNCTIONS = 0;
  var ELIMINATE_DUPLICATE_FUNCTIONS_PASSES = 5;
  
  // This tries to evaluate global ctors at compile-time, applying their effects
  // into the mem init file. This saves running code during startup, and also
  // allows removing the global ctor functions and other code that only they used,
  // so this is also good for reducing code size. However, this does make the
  // compile step much slower.
  //
  // This basically runs the ctors during compile time, seeing if they execute
  // safely in a sandbox. Any ffi access out of asm.js causes failure, as it could
  // do something nondeterministic and/or alter some other state we don't see. If
  // all the global ctor does is pure computation inside asm.js, it should be ok.
  // Run with EMCC_DEBUG=1 in the env to see logging, and errors when it fails to
  // eval (you'll see a message, or a stack trace; in the latter case, the
  // functions on the stack should give you an idea of what ffi was called and
  // why, and perhaps you can refactor your code to avoid it, e.g., remove
  // mallocs, printfs in global ctors).
  //
  // This optimization can increase the size of the mem init file, because ctors
  // can write to memory that would otherwise be in a zeroinit area. This may not
  // be a significant increase after gzip, if there are mostly zeros in there, and
  // in any case the mem init increase would be offset by a code size decrease.
  // (Unless you have a small ctor that writes 'random' data to memory, which
  // would reduce little code but add potentially lots of uncompressible data.)
  //
  // LLVM's GlobalOpt *almost* does this operation. It does in simple cases, where
  // LLVM IR is not too complex for its logic to evaluate, but it isn't powerful
  // enough for e.g. libc++ iostream ctors. It is just hard to do at the LLVM IR
  // level - LLVM IR is complex and getting more complex, this would require
  // GlobalOpt to have a full interpreter, plus a way to write back into LLVM IR
  // global objects.  At the asm.js level, however, everything has been lowered
  // into a simple low level, and we also just need to write bytes into an array,
  // so this is easy for us to do, but not for LLVM. A further issue for LLVM is
  // that it doesn't know that we will not link in further code, so it only tries
  // to optimize ctors with lowest priority. We do know that, and can optimize all
  // the ctors.
  var EVAL_CTORS = 0;
  
  // Whether to emit DWARF in a wasm file on the side (this is not called
  // "split"/"separate" because there is already a DWARF concept by that name).
  // When DWARF is on the side, the main file has no DWARF info, while the side
  // file, ending in .debug.wasm, has the same wasm binary + all the debug
  // sections.
  // This has no effect if DWARF is not being emitted.
  var SIDE_DEBUG = 0;
  
  // see http://kripken.github.io/emscripten-site/docs/debugging/CyberDWARF.html
  // [fastcomp-only]
  var CYBERDWARF = 0;
  
  // Path to the CyberDWARF debug file passed to the compiler
  // [fastcomp-only]
  var BUNDLED_CD_DEBUG_FILE = "";
  
  // Is enabled, use the JavaScript TextDecoder API for string marshalling.
  // Enabled by default, set this to 0 to disable.
  // If set to 2, we assume TextDecoder is present and usable, and do not emit
  // any JS code to fall back if it is missing.
  var TEXTDECODER = 1;
  
  // Embind specific: If enabled, assume UTF-8 encoded data in std::string binding.
  // Disable this to support binary data transfer.
  var EMBIND_STD_STRING_IS_UTF8 = 1;
  
  // If set to 1, enables support for transferring canvases to pthreads and
  // creating WebGL contexts in them, as well as explicit swap control for GL
  // contexts. This needs browser support for the OffscreenCanvas specification.
  var OFFSCREENCANVAS_SUPPORT = 0;
  
  // If you are using PROXY_TO_PTHREAD with OFFSCREENCANVAS_SUPPORT, then specify
  // here a comma separated list of CSS ID selectors to canvases to proxy over
  // to the pthread at program startup, e.g. '#canvas1, #canvas2'.
  var OFFSCREENCANVASES_TO_PTHREAD = "#canvas";
  
  // If set to 1, enables support for WebGL contexts to render to an offscreen
  // render target, to avoid the implicit swap behavior of WebGL where exiting any
  // event callback would automatically perform a "flip" to present rendered
  // content on screen. When an Emscripten GL context has Offscreen Framebuffer
  // enabled, a single frame can be composited from multiple event callbacks, and
  // the swap function emscripten_webgl_commit_frame() is then explicitly called
  // to present the rendered content on screen.
  //
  // The OffscreenCanvas feature also enables explicit GL frame swapping support,
  // and also, -s OFFSCREEN_FRAMEBUFFER=1 feature can be used to polyfill support
  // for accessing WebGL in multiple threads in the absence of OffscreenCanvas
  // support in browser, at the cost of some performance and latency.
  // OffscreenCanvas and Offscreen Framebuffer support can be enabled at the same
  // time, and allows one to utilize OffscreenCanvas where available, and to fall
  // back to Offscreen Framebuffer otherwise.
  var OFFSCREEN_FRAMEBUFFER = 0;
  
  // If nonzero, Fetch API (and hence ASMFS) supports backing to IndexedDB. If 0, IndexedDB is not utilized. Set to 0 if
  // IndexedDB support is not interesting for target application, to save a few kBytes.
  var FETCH_SUPPORT_INDEXEDDB = 1;
  
  // If nonzero, prints out debugging information in library_fetch.js
  var FETCH_DEBUG = 0;
  
  // If nonzero, enables emscripten_fetch API.
  var FETCH = 0;
  
  // Whether to use an asm.js fetch worker when using FETCH. Note that this is
  // only relevant for fastcomp, where we support asm.js. As a result, some
  // synchronous fetch operations that depend on the fetch worker may not work
  // with the wasm backend, like waiting or IndexedDB.
  // Currently will always be set to 0 on WASM backend.
  var USE_FETCH_WORKER = 1;
  
  // If set to 1, uses the multithreaded filesystem that is implemented within the
  // asm.js module, using emscripten_fetch. Implies -s FETCH=1.
  var ASMFS = 0;
  
  // If set to 1, embeds all subresources in the emitted file as base64 string
  // literals. Embedded subresources may include (but aren't limited to) wasm,
  // asm.js, and static memory initialization code.
  //
  // When using code that depends on this option, your Content Security Policy may
  // need to be updated. Specifically, embedding asm.js requires the script-src
  // directive to whitelist 'unsafe-inline', and using a Worker requires the
  // child-src directive to whitelist blob:. If you aren't using Content Security
  // Policy, or your CSP header doesn't include either script-src or child-src,
  // then you can safely ignore this warning.
  var SINGLE_FILE = 0;
  
  // if set to 1, then generated WASM files will contain a custom
  // "emscripten_metadata" section that contains information necessary
  // to execute the file without the accompanying JS file.
  var EMIT_EMSCRIPTEN_METADATA = 0;
  
  // If set to 1, all JS libraries will be automaticially available at link time.
  // This gets set to 0 in STRICT mode (or with MINIMAL_RUNTIME) which mean you
  // need to explictly specify -lfoo.js in at link time in order to access
  // library function in library_foo.js.
  var AUTO_JS_LIBRARIES = 1;
  
  // Specifies the oldest major version of Firefox to target. I.e. all Firefox
  // versions >= MIN_FIREFOX_VERSION
  // are desired to work. Pass -s MIN_FIREFOX_VERSION=majorVersion to drop support
  // for Firefox versions older than < majorVersion.
  // Firefox ESR 60.5 (Firefox 65) was released on 2019-01-29.
  var MIN_FIREFOX_VERSION = 65;
  
  // Specifies the oldest version of desktop Safari to target. Version is encoded
  // in MMmmVV, e.g. 70101 denotes Safari 7.1.1.
  // Safari 12.0.0 was released on September 17, 2018, bundled with macOS 10.14.0
  // Mojave
  var MIN_SAFARI_VERSION = 120000;
  
  // Specifies the oldest version of Internet Explorer to target. E.g. pass -s
  // MIN_IE_VERSION = 11 to drop support for IE 10 and older.
  // Internet Explorer is at end of life and does not support WebAssembly.
  // MAX_INT (0x7FFFFFFF) specifies that target is not supported.
  var MIN_IE_VERSION = 0x7FFFFFFF;
  
  // Specifies the oldest version of Edge (EdgeHTML, the non-Chromium based
  // flavor) to target. E.g. pass -s MIN_EDGE_VERSION=40 to drop support for
  // EdgeHTML 39 and older.
  // Edge 44.17763 was released on November 13, 2018
  var MIN_EDGE_VERSION = 44;
  
  // Specifies the oldest version of Chrome. E.g. pass -s MIN_CHROME_VERSION=58 to
  // drop support for Chrome 57 and older.
  // Chrome 75.0.3770 was released on 2019-06-04
  var MIN_CHROME_VERSION = 75;
  
  // Tracks whether we are building with errno support enabled. Set to 0
  // to disable compiling errno support in altogether. This saves a little
  // bit of generated code size in applications that do not care about
  // POSIX errno variable. Setting this to 0 also requires using --closure
  // for effective code size optimizations to take place.
  var SUPPORT_ERRNO = 1;
  
  // If true, uses minimal sized runtime without POSIX features, Module,
  // preRun/preInit/etc., Emscripten built-in XHR loading or library_browser.js.
  // Enable this setting to target the smallest code size possible.  Set
  // MINIMAL_RUNTIME=2 to further enable even more code size optimizations. These
  // opts are quite hacky, and work around limitations in Closure and other parts
  // of the build system, so they may not work in all generated programs (But can
  // be useful for really small programs)
  var MINIMAL_RUNTIME = 0;
  
  // If set to 1, MINIMAL_RUNTIME will utilize streaming WebAssembly compilation,
  // where WebAssembly module is compiled already while it is being downloaded.
  // In order for this to work, the web server MUST properly serve the .wasm file
  // with a HTTP response header "Content-Type: application/wasm". If this HTTP
  // header is not present, e.g. Firefox 73 will fail with an error message
  //    TypeError: Response has unsupported MIME type
  // and Chrome 78 will fail with an error message
  //    Uncaught (in promise) TypeError: Failed to execute 'compile' on
  //    'WebAssembly': Incorrect response MIME type. Expected 'application/wasm'.
  // If set to 0 (default), streaming WebAssembly compilation is disabled, which
  // means that the WebAssembly Module will first be downloaded fully, and only
  // then compilation starts.
  // For large .wasm modules and production environments, this should be set to 1
  // for faster startup speeds. However this setting is disabled by default
  // since it requires server side configuration and for really small pages there
  // is no observable difference (also has a ~100 byte impact to code size)
  var MINIMAL_RUNTIME_STREAMING_WASM_COMPILATION = 0;
  
  // If set to 1, MINIMAL_RUNTIME will utilize streaming WebAssembly instantiation,
  // where WebAssembly module is compiled+instantiated already while it is being
  // downloaded. Same restrictions/requirements apply as with
  // MINIMAL_RUNTIME_STREAMING_WASM_COMPILATION.
  // MINIMAL_RUNTIME_STREAMING_WASM_COMPILATION and
  // MINIMAL_RUNTIME_STREAMING_WASM_INSTANTIATION cannot be simultaneously active.
  // Which one of these two is faster depends on the size of the wasm module,
  // the size of the JS runtime file, and the size of the preloaded data file
  // to download, and the browser in question.
  var MINIMAL_RUNTIME_STREAMING_WASM_INSTANTIATION = 0;
  
  // If building with MINIMAL_RUNTIME=1 and application uses sbrk()/malloc(),
  // enable this. If you are not using dynamic allocations, can set this to 0 to
  // save code size. This setting is ignored when building with -s
  // MINIMAL_RUNTIME=0.
  var USES_DYNAMIC_ALLOC = 1;
  
  // Advanced manual dead code elimination: Specifies the set of runtime JS
  // functions that should be imported to the asm.js/wasm module.  Remove elements
  // from this list to make build smaller if some of these are not needed.  In
  // Wasm -O3/-Os builds, adjusting this is not necessary, as the Meta-DCE pass is
  // able to remove these, but if you are targeting asm.js or doing a -O2 build or
  // lower, then this can be beneficial.
  var RUNTIME_FUNCS_TO_IMPORT = ['abort', 'setTempRet0', 'getTempRet0']
  
  // If true, compiler supports setjmp() and longjmp(). If false, these APIs are
  // not available.  If you are using C++ exceptions, but do not need
  // setjmp()+longjmp() API, then you can set this to 0 to save a little bit of
  // code size and performance when catching exceptions.
  var SUPPORT_LONGJMP = 1;
  
  // If set to 1, disables old deprecated HTML5 API event target lookup behavior.
  // When enabled, there is no "Module.canvas" object, no magic "null" default
  // handling, and DOM element 'target' parameters are taken to refer to CSS
  // selectors, instead of referring to DOM IDs.
  var DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR = 1;
  
  // Certain browser DOM API operations, such as requesting fullscreen mode
  // transition or pointer lock require that the request originates from within
  // an user initiated event, such as mouse click or keyboard press. Refactoring
  // an application to follow this kind of program structure can be difficult, so
  // HTML5_SUPPORT_DEFERRING_USER_SENSITIVE_REQUESTS=1 flag allows transparent
  // emulation of this by deferring synchronous fullscreen mode and pointer lock
  // requests until a suitable event callback is generated. Set this to 0
  // to disable support for deferring to save code space if your application does
  // not need support for deferred calls.
  var HTML5_SUPPORT_DEFERRING_USER_SENSITIVE_REQUESTS = 1;
  
  // Specifies whether the generated .html file is run through html-minifier. The
  // set of optimization passes run by html-minifier depends on debug and
  // optimization levels. In -g2 and higher, no minification is performed. In -g1,
  // minification is done, but whitespace is retained. Minification requires at
  // least -O1 or -Os to be used. Pass -s MINIFY_HTML=0 to explicitly choose to
  // disable HTML minification altogether.
  var MINIFY_HTML = 1;
  
  // Whether we *may* be using wasm2js. This compiles to wasm normally, but lets
  // you run wasm2js *later* on the wasm, and you can pick between running the
  // normal wasm or that wasm2js code. For details of how to do that, see the
  // test_maybe_wasm2js test.  This option can be useful for debugging and
  // bisecting.
  var MAYBE_WASM2JS = 0;
  
  // The size of our shadow memory.
  // By default, we have 32 MiB. This supports 256 MiB of real memory.
  var ASAN_SHADOW_SIZE = 33554432;
  
  // Internal: Tracks whether Emscripten should link in exception throwing (C++
  // 'throw') support library. This does not need to be set directly, but pass
  // -fno-exceptions to the build disable exceptions support. (This is basically
  // -fno-exceptions, but checked at final link time instead of individual .cpp
  // file compile time) If the program *does* contain throwing code (some source
  // files were not compiled with `-fno-exceptions`), and this flag is set at link
  // time, then you will get errors on undefined symbols, as the exception
  // throwing code is not linked in. If so you should either unset the option (if
  // you do want exceptions) or fix the compilation of the source files so that
  // indeed no exceptions are used).
  // TODO(sbc): Move to settings_internal (current blocked due to use in test
  // code).
  var DISABLE_EXCEPTION_THROWING = 0;
  
  // Whether we should use the offset converter.  This is needed for older
  // versions of v8 (<7.7) that does not give the hex module offset into wasm
  // binary in stack traces, as well as for avoiding using source map entries
  // across function boundaries.
  var USE_OFFSET_CONVERTER = 0;
  
  // If set to 1, the JS compiler is run before wasm-ld so that the linker can
  // report undefined symbols within the binary.  Without this option that linker
  // doesn't know which symmbols might be defined JS and so reporting of undefined
  // symbols is deleyed until the JS compiler is run.
  // [link]
  var LLD_REPORT_UNDEFINED = 0;
  
  //===========================================
  // Internal, used for testing only, from here
  //===========================================
  
  // Internal (testing only): Disables the blitOffscreenFramebuffer VAO path.
  var OFFSCREEN_FRAMEBUFFER_FORBID_VAO_PATH = 0;
  
  // Internal (testing only): Forces memory growing to fail.
  var TEST_MEMORY_GROWTH_FAILS = 0;
  
  // Advanced: Customize this array to reduce the set of asm.js runtime variables
  // that are generated. This allows minifying extra bit of asm.js code from unused
  // runtime code, if you know some of these are not needed.
  // (think of this as advanced manual DCE)
  // TODO(sbc): Move to settings_internal (current blocked due to use in test
  // code).
  var ASM_PRIMITIVE_VARS = ['__THREW__', 'threwValue', 'setjmpId', 'tempInt', 'tempBigInt', 'tempBigIntS', 'tempValue', 'tempDouble', 'tempFloat', 'tempDoublePtr', 'STACKTOP', 'STACK_MAX']
  
  // Legacy settings that have been removed or renamed.
  // For renamed settings the format is:
  // [OLD_NAME, NEW_NAME]
  // For removed settings (which now effectively have a fixed value and can no
  // longer be changed) the format is:
  // [OPTION_NAME, POSSIBLE_VALUES, ERROR_EXPLANATION], where POSSIBLE_VALUES is
  // an array of values that will still be silently accepted by the compiler.
  // First element in the list is the canonical/fixed value going forward.
  // This allows existing build systems to keep specifying one of the supported
  // settings, for backwards compatibility.
  var LEGACY_SETTINGS = [
    ['BINARYEN', 'WASM'],
    ['BINARYEN_ASYNC_COMPILATION', 'WASM_ASYNC_COMPILATION'],
    ['UNALIGNED_MEMORY', [0], 'forced unaligned memory not supported in fastcomp'],
    ['FORCE_ALIGNED_MEMORY', [0], 'forced aligned memory is not supported in fastcomp'],
    ['PGO', [0], 'pgo no longer supported'],
    ['QUANTUM_SIZE', [4], 'altering the QUANTUM_SIZE is not supported'],
    ['FUNCTION_POINTER_ALIGNMENT', [2], 'Starting from Emscripten 1.37.29, no longer available (https://github.com/emscripten-core/emscripten/pull/6091)'],
    ['BUILD_AS_SHARED_LIB', [0], 'Starting from Emscripten 1.38.16, no longer available (https://github.com/emscripten-core/emscripten/pull/7433)'],
    ['SAFE_SPLIT_MEMORY', [0], 'Starting from Emscripten 1.38.19, SAFE_SPLIT_MEMORY codegen is no longer available (https://github.com/emscripten-core/emscripten/pull/7465)'],
    ['SPLIT_MEMORY', [0], 'Starting from Emscripten 1.38.19, SPLIT_MEMORY codegen is no longer available (https://github.com/emscripten-core/emscripten/pull/7465)'],
    ['BINARYEN_METHOD', ['native-wasm'], 'Starting from Emscripten 1.38.23, Emscripten now always builds either to Wasm (-s WASM=1 - default), or to asm.js (-s WASM=0), other methods are not supported (https://github.com/emscripten-core/emscripten/pull/7836)'],
    ['PRECISE_I64_MATH', [1, 2], 'Starting from Emscripten 1.38.26, PRECISE_I64_MATH is always enabled (https://github.com/emscripten-core/emscripten/pull/7935)'],
    ['MEMFS_APPEND_TO_TYPED_ARRAYS', [1], 'Starting from Emscripten 1.38.26, MEMFS_APPEND_TO_TYPED_ARRAYS=0 is no longer supported. MEMFS no longer supports using JS arrays for file data (https://github.com/emscripten-core/emscripten/pull/7918)'],
    ['ERROR_ON_MISSING_LIBRARIES', [1], 'missing libraries are always an error now'],
    ['EMITTING_JS', [1], 'The new STANDALONE_WASM flag replaces this (replace EMITTING_JS=0 with STANDALONE_WASM=1)'],
    ['SKIP_STACK_IN_SMALL', [0, 1], 'SKIP_STACK_IN_SMALL is no longer needed as the backend can optimize it directly'],
    ['SAFE_STACK', [0], 'Replace SAFE_STACK=1 with STACK_OVERFLOW_CHECK=2'],
    ['MEMORY_GROWTH_STEP', 'MEMORY_GROWTH_LINEAR_STEP'],
    ['WASM_OBJECT_FILES', [1], 'Use -flto or -fto=thin instead'],
    ['TOTAL_MEMORY', 'INITIAL_MEMORY'],
    ['WASM_MEM_MAX', 'MAXIMUM_MEMORY'],
    ['BINARYEN_MEM_MAX', 'MAXIMUM_MEMORY'],
  ];
  