Apparent codegen bug when building optimized targetting WASI

I've hit a bug that is proving extremely hard to pin down or reduce in any way. So I'm really just looking for suggestions on what I might do to proceed, since I realize I don't have enough info for anyone else to look into it. I'm not even sure if this is the right place vs LLVM, but since it so far has shown up only in WASI builds, I'll start here.

It manifests in a quite bizarre way. I have a std::stringstream ss into which I insert character through a std::ostream_iterator<char> out:

char ch = /**/;
*out++ = ch;

What I'm getting out of the stringstream is not the characters inserted, but a string of digits of the character representations. For example inserting a space character yields not " ", but "32". I initially couldn't even fathom how this could happen, but I discovered that ostream_iterator<T> apparently maps to ss << T(x), so it seems like the only feasible explanation is that somehow the iterator is being incorrectly treated as ostream_iterator<int> or similar. This is very definitely not the case in my code (note the program behaves as expected in non-optimized WASI builds, and also optimized builds with the same clang version targetting x86).

Unfortunately repros are complicated by the fact my project uses C++20 modules and this issue is deep in the module dependency graph, so there is no simple way to create a preprocessed repro. And as for reduction, if I so much as breath on the code, the issue goes away.

• add an additional lambda capture to try to log more info when the issue occurs -> no bug
• merely adding #include <iostream> at the top of the file -> no bug
• copying the function template which does the iterator assignment directly above the call site/into another module interface, and calling that instead -> no bug

Using modules I've got plenty of experience with compiler bugs, but very little when it comes to optimization-related bugs or looking at generated code. Does anyone have any suggestions or tricks for trying to pin down the issue or get more useful information in a case like this? Also please let me know if this would be better posted to the LLVM project.

Start with the optimized WASI build that changes ostream_iterator output in std::stringstream, and compare it with the non-optimized WASI and optimized x86 builds. The issue mentions C++20 modules, but no reduced reproducer, file, test, or generated-code entry point; progress would require isolating a reproducible case and determining whether it belongs in wasi-sdk or LLVM.