We found another issue where the compiler enters an infinite loop at this revision.
The infinite loop reproduces up until revision 7db87a66b0206af027724fc1704e5e5ce7772a45 where the compiler exits with error:

Just tried the patch and it fixes our issue! Waiting unpatiantly for you to submit the fix forward!

In D159205#4648763, @ABataev wrote:

In D159205#4648753, @bgraur wrote:

Is there something else above, like assertion message? It would really help more rather than the rest of the stack trace

No, I've built the code with assertions enabled in the compiler and no assertion was triggered. The stack trace is all I get.

Ok, I'll try to prepare a fix, but it would be good to see a reproducer.

Is there something else above, like assertion message? It would really help more rather than the rest of the stack trace

Sorry I cut the first few lines! Here's the complete stack trace:

Heads-up: this revision is causing a crash in the LTO compiler backend.

@khei4 the last commit is causing again lots of false positive for tests executed under asan.

In D152281#4570151, @bgraur wrote:

Heads-up: this is likely causing a miscompile. We're working on a reproducer.

Heads-up: this is likely causing a miscompile. We're working on a reproducer.

Thanks for the quick fix @arsenm !

@arsenm it looks like calling std::frexp(long double, int) is changing some global state as floating point operations following it start to produce NaNs.

@arsenm we bisected an eigen3 C++ test failure to clang: Use new frexp intrinsic for builtins and add f16 version which got reverted in 0c545a441285a73e00b859dd52f1a85cb9eeeefc and then reapplied in this commit (b15bf305ca3e9ce63aaef7247d32fb3a75174531).

Thanks to @goncharov for submitting the revert in df3a8f376084cf5e319bccd843105979d0f3b6f1!

@Allen I got to a repro that requires a headers and two cc files.

@Allen would you be so kind to revert the patch while we're working on the reproducer (might take some time)?

@Allen the latest patch is again causing a similar miscompile as the previous one I reported.

@Allen this last patch is causing a miscompile again.

In D150440#4337821, @skan wrote:

@bgraur I will revert D150068 first, so that we won't have to revert two separate commits if there is a coming issue. The fix in this patch seems straightforward to me and since D150068 was reviewed already, I will try to reland it with this fix.

@aaron.ballman your patch (1395cde24b3641e284bb1daae7d56c189a2635e3) fixed all issues we encountered. Thanks!!

We see the same compilation error as the one reported by @sbc100 in several other C libraries.

In D147243#4246924, @alexfh wrote:

In D147243#4246777, @RKSimon wrote:

Thanks @alexfh I have an idea what's going on and will deal with it tomorrow.

Thanks! It would be nice to have a fix or revert soon, since we're blocked on this.

What's the resolution here? Can we revert this and continue the discussions independently?
We can always re-land this change if the conclusion is that the approach here is the one that we want.

We've found another clang crasher caused by this change.

@Allen test unittests/ProfileData/ProfileDataTests fails when built with optimisations level -O1 with clang including this patch.

The correct way to using a custom built libc++ is documented here: https://libcxx.llvm.org/UsingLibcxx.html#using-a-custom-built-libc

I tried myself to reproduce the miscompile building clang from the LLVM source tree using the cmake method and found out that it is important to use the standard library headers from the LLVM sources and not the system headers which may be an older version.

In D142535#4115401, @samparker wrote:

Hi @bgraur Thanks for the reproducer, but I'm unable to reproduce the issue on my x64 box... What platform were you targeting? Could you please confirm that the reproducer still demonstrates the bug?

Thanks a lot for reverting!

In D142535#4112830, @samparker wrote:

Any update on that reproducer @bgraur?

Heads-up: this patch is producing miscompiles in our code.
We have verified the code is correct and the test passes without this patch and crashes with it.

We're seeing a lot of fallout from this patch and they all look related to the ODR violations that seem to be intentionally added here: both the patch description and the comment for the __exception_guard mention explicitly that combinations of code compiled with exceptions and without exceptions are common.

In rG9ddff66d0c9c3e18d56e6b20aa26a2a8cdfb6d2b#1157426, @lebedev.ri wrote:

In rG9ddff66d0c9c3e18d56e6b20aa26a2a8cdfb6d2b#1157331, @bgraur wrote:

Hi Roman, this revision was identified as the culprit for a miscompile in another part of the code than what @alexfh was checking.
It would be great if you could revert this patch while waiting for a reproducer. What do you think?

What is the progress on that reproducer?
As per https://github.com/ClangBuiltLinux/linux/issues/1770#issuecomment-1356486702, it is not obvious where the actual problem lies.

Hi Roman, this revision was identified as the culprit for a miscompile in another part of the code than what @alexfh was checking.
It would be great if you could revert this patch while waiting for a reproducer. What do you think?

Thanks a lot Alina!

Heads-up: a root cause is pointing to this patch for a miscompile that leads to an infinite loop in one of our tests.
Working on a reproducer.

In D133638#3850477, @philnik wrote:

@rupprecht I don't think there is a bug here. You allocator isn't conforming. The difference between your example and the standard example is that the standard example is a template, which can be rebound by default (see https://eel.is/c++draft/allocator.requirements#general-18). This is actually one of the bugs this patch is trying to catch.

Heads-up: we have found this revision to be the culprit for an LTO compilation crash.

@tstellar FYI the clang crash report from @joanahalili and the new compilation errors report from @asmok-g, both introduced by this patch.
Is a revert warranted here?

@SimplyDanny given the reports from @joanahalili and @asmok-g are you considering a revert for this patch?

Hi folks,

Thanks a lot for the quick fix!!

@philnik considering this commit breaks std::search_n() could you please revert?

This commit breaks std::search_n().

This commit causes clang to crash when compiling the attached reproducer with the following compilation command:

I can confirm the clang crash is fixed with the updated patch.
Thanks for fixing Alexey!

Since we had so many issues related to the initial patch (https://reviews.llvm.org/D115955), would you please consider reverting that and work on the fix without the stress of adding new issues?

Please find attached the reproducer for the crash.

Here's a stack of the crash:

I was trying to confirm that this patch fixes a mis-compile and it seems clang crashes with this patched in (does not crash without the patch).

An LGTM on the revert would be greatly appreciated.

Thanks! Created a revert here: https://reviews.llvm.org/D115528

In D110867#3183005, @lebedev.ri wrote:

In D110867#3182991, @bgraur wrote:

We have root caused to this revision a mis-compile affecting AMD Rome machines.
I have attached a reproducer program that shows the problem when compiled with -O2 or -O3.

Please revert this change until you have a chance to look at the problem.

NOTE: the repro uses the abseil library that can be found at https://github.com/abseil/abseil-cpp. The reproducer might probably be reduced more (if needed) but it would be great if you could revert early.

Reproducer:

repro_git.cc1 KBDownload

Please post standalone reproducer, one that does not require guessing versions of external dependecies,
and the actual reproduction steps, as in the actual complete compilation and run command.

We have root caused to this revision a mis-compile affecting AMD Rome machines.
I have attached a reproducer program that shows the problem when compiled with -O2 or -O3.

Early heads up that this revision causes a large regression in compilation time for some of our internal source files: we are seeing an almost 20x increase in compilation times for some files (from 42s to 728s).

This revision removes the only available methods to convert std::chrono::file_time_type to/from anything else.

The reverted commit introduced an error when std::rel_ops are used.
Here's a small reproducer:

In D105887#2874000, @ldionne wrote:

Just curious -- why is that needed? Is it not possible to make this change upstream? Otherwise, we'll have to do the same thing again when we update Google Benchmark next.

Hi Louis,

Not sure how the build bots are configured.

The descritption is: "Both newly added tests fail in Release."

Ideally, this roll-forward should also have included this fix.
The test failure was 100% reproducible.