Thanks, @philnik ; that patch indeed works. I appreciate the quick reply, too.

I'm seeing new compilation errors from the moved allocator static_assert in this patch.

For the record, so far we've seen this showing up in the following:

• A case in a notoriously warning-heavy third-party library where we'd backported a file from a newer version and didn't quite fix all the internal API mismatches.
• A ten-year-old bug in a local patch to another third-party library, where a function-pointer parameter was defined as returning a void and then assigned to a function-pointer that returns a void *.
• A probably-innocuous bug in a local patch to yet another third-party library, where we were passing an int foo(char *, char *) function to GLIBC's qsort, which expects a function with a signature of int foo(void *, void *).
• A case where https://gitlab.freedesktop.org/pixman/pixman/-/commit/e0d4403e78a7af8f4be4110ae25e9c3d1ac93a78 wasn't applied to our local version. This is also probably an innocuous case, not a "real" bug.
• A case where SciPy's extension has a function that uses void * for a FILE * pointer (https://github.com/scipy/scipy/blob/main/scipy/spatial/_qhull.pyx#L187, second argument) while the corresponding C code's function has a real FILE * pointer (https://github.com/qhull/qhull/blob/master/src/libqhull_r/io_r.h#L97). The SciPy function also uses a void * for an argument of a struct type, which seems rather odd to me given that it just defined the type two lines earlier.

@wrengr : Looks fixed; thanks!

I'm seeing test warning/errors from this:

We're seeing a number of LLDB test failures from this change. If I'm understanding correctly, that's working by design because we're building the test code with a version of LLVM that's from a revision that's not quite as recent as the LLDB code we're testing.

Thanks much! We'll get you a test case as soon as we can.

As a heads-up: We don't have a reduced testcase yet, but we're seeing some significant errors in an FFT test that root-cause to this change.

In D99790#2678674, @lebedev.ri wrote:

In D99790#2678384, @brooksmoses wrote:

In any case, thanks for the quick reply, and I'll figure out a small reproducer if we find something that isn't UB.

Nono, you misunderstand, i want the samples *with* UB.
I will then revert this, and add UBSan check to catch that UB first.

In D99790#2677919, @lebedev.ri wrote:

In D99790#2677917, @brooksmoses wrote:

As a heads up, I'm seeing segfaults on internal code as a result of this change, as well as errors in Eigen's unalignedassert.cpp test (specifically, this line asserts: https://github.com/madlib/eigen/blob/master/test/unalignedassert.cpp#L151).

Would be good to have a small standalone reproducer.
Not really sure how we can end up with a misaligned this, but it sounds like UB.

As a heads up, I'm seeing segfaults on internal code as a result of this change, as well as errors in Eigen's unalignedassert.cpp test (specifically, this line asserts: https://github.com/madlib/eigen/blob/master/test/unalignedassert.cpp#L151).

FWIW, this now causes Clang to produce an error on this code, when it didn't before:

Aha, okay. I hadn't realized that this optimization had a -fno-delete-null-pointer-checks option to disable it. I agree that since that's available there's no call for a rollback.

So, I have bad news: This causes OpenJDK to segfault. The relevant code is here:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/memory/arena.cpp#L311

As a heads-up: This is causing a lot of Clang segfaults in Google's builds with sanitizers enabled. We're working work on a reduced testcase, but wanted to let you know while we do that.

In D83440#2143461, @nlopes wrote:

Yes, it may hide some warnings.
But that's life. Optimizations do hide programming errors. This is not the only one for sure. But it's ok as you are checking the code that will run. If the compiler can "fix" bugs automatically, then developers don't need to worry about those. As long as you keep running these checks continuously to track changes in the compiler like this one :)

Replying to my own question, as I was able to test this sooner than I expected: Yes, it looks like the new MSAN warnings remain after this revision. Excellent! I think that proves that this was a useful fix. :)

I'd erroneously made this comment on the revision (where I think nobody will see it) rather than here, so copying it here:

A question about this: We got a couple of dozen MSAN warnings in the Google codebase from the revision that removed these -- I'm guessing that perhaps what happened was that the undef in question was a use-of-uninitialized-value, and this optimization was hiding the use so the MSAN checks didn't trigger. Is re-enabling this going to make those MSAN warnings go away again, re-hiding this undefined behavior?

This breaks the build with an unused-variable warning:

Hey, so I'm seeing these tests starting to fail with llc errors. The output looks like this (after going through the output-scanning layer):

Unfortunately, we (Google) are seeing some regressions on our internal benchmarks on x86_64 -- mostly around 2%, but in some cases a good bit more -- from this revision and some of the subsequent revisions in the series, notably r362217. Just wanted to give you a heads-up at this point -- we're still working to try to understand the underlying reasons and get a reproducing test-case, but it looks like these are going to block our internal release until they're addressed.

For what it's worth, I was also seeing some run-time errors on x86 coming from the change that this reverts. I haven't dug into things to track them down, beyond determining that this change makes them go away again.

Thanks for the quick fix for bug 41973!

While you're doing that, maybe also fix "refer different places" in the comment on line 447 to be "refer to different places". :)

Thanks for the summary, John. To confirm, I found two examples of bugs involving local variables, as well as the field-based examples. And, indeed, all of the false positives were in unit tests.

A further concern about this in the general case from the reviewer of one of my test-cleanup changes: The "var = *&var" idiom is not necessarily equivalent to "var = var" in cases of user-defined types, because operator& may be overloaded.

Some further statistics, now that I've done a full cleanup on our code:

Further note: I'm noticing that nearly all the signal is from -Wself-assign-field and all the noise is from -Wself-assign. So that would be one obvious way to make this higher-signal in what's enabled in -Wall, if that were a desire.

I have noticed two things when attempting to release LLVM with this revision internally at Google:

We're seeing about 10% regressions in an internal benchmark as a result of this change. Still digging further, but wanted to send a heads-up.