These intrinsics are necessary to implement Nontrapping Float To Int Conversions, which have now been merged with the mainline WebAssembly spec. Without these intrinsics, a significant amount of code is required to get them to function (using Rust's implementation as an example, amount of code varies by language). Since the WebAssembly standard now requires these operations, I would like to know the status of this PR and how close it is to being merged.

Removed unnecessary formatting changes. I do not have commit access @aganea so someone else will have to merge this change.

I changed it to ::instances, but clang-format tried to reformat a bunch of code unrelated to my changes, so I only ran it against Writer.cpp to minimize spurious changes.

This update removes the debuginfo fix, which is no longer needed, and instead moves outputSections into OutputSection and calls it directly from link()

It looks like this time around, the global list that was added has been properly cleaned up in link(), so this should be fine. Of course, the fixes that were mentioned still haven't been merged, so as of right now LLVM 10's LLD linker crashes on windows when used multiple times, but apparently nobody cares about that right now. I can attempt to test this modification on my fork to see if it actually works, if people are willing to commit to actually fixing the memory cleanup errors.

After further testing, this actually doesn't work, but only if you are loading an associated PDB file. I have no idea what's going on, because I don't understand the internals of TypeServerSource, but it's throwing an assertion error at DebugTypes.cpp:191

Update with full context

Moved the clear commands to where @ruiu suggested. I was unable to upload a full context diff because the web interface refuses to work properly.

Addressed by https://reviews.llvm.org/D70292

I am not particularly convinced that this will fix the problem, as it simply moves the problem around - instead of having to remember to clean up global variables, now programmers have to remember to initialize them with invalid values. This would certainly make it easier to detect errors once you realize there is one, but if someone silently adds a global variable and forgets to initialize it, you're back at square one. The only reliable way to fix the problem is to create an object whose constructor or destructor is automatically called when necessary, which is why I suggested a global container object. Adding anything to the global container object doesn't require the programmer to remember anything, because the destructor will automatically destruct everything inside of it. If this is simply not possible, some sort of baseline test as suggested by MaskRay is likely your only option.

I can confirm this change would satisfy my use-case, although another reviewer ought to look over it.

Yes, I am calling lld::elf::link from my program, which statically links LLD as a library. I can create a change that adds a diag stream to all the linker calls, but this would touch quite a lot of files. It may be more appropriate to close this change and to create a new change for adding a new stream.

I am calling LLD from within another command line application, and I only want to display output from LLD if there is an actual error, or the user has enabled verbose logging, but several places in LLD use message() during the linking process even if it succeeds, which will output directly to stdout with no way for me to portably redirect it (unless I use freopen, which permanently redirects it to a file, forever, and cannot be restored afterwards). If there needs to be a separate stream for non-error messages, then there should be a way to pass that into the link() function as well, instead of bypassing everything and outputting directly to stdout.

I do not have access to anything. The only repo I currently have cloned is my fork of the official git repository.

That is not an acceptable solution. This compiler is an embedded, statically linked library that can be used by other programs. It is not a standalone compiler. If the library is statically linked, there is literally no way to start a new process without forcing every single user of my library to support their own program being called with a special option for the sole purpose of invoking a linker. Since one of the intended uses, for example, is a game engine script library, which would compile a webassembly script for a map, this compilation process cannot require the game to support calling it's own executable, or link the script engine as a DLL for the sole purpose of having the script engine then load it's own DLL in a new process. These are not reasonable restrictions to have on what is supposed to be a self-contained compiler.