IMHO, we could use printf() in gwpasan directly, with a guard against recursive malloc.

I don't think this will work in a signal-safe manner. The only times that GwpAsan calls printf() is in the signal handler, and even if we temporarily disable sampled allocations, we still are exercising non-reentrant functions in a signal handler.

LGTM

If the atomic load ends up on the hot path, we could try moving it to the same cache line as NextSampleCounter. That would make it thread local, but it can be initialized from the global variable on the slow path.

LGTM

In D60617#1467093, @glider wrote:

In D60617#1464971, @eugenis wrote:

Please test the case when alloca can not be found.
See https://bugs.llvm.org/show_bug.cgi?id=41481 for the reference.

Ok, will do. The repro in the bug doesn't produce IR containing a select statement for me, but the idea is clear.

With this change msan will start detecting new bugs, ex.:
for (int i = 0; ...; ++i) {

int x;
if (i == 0) x=0;
read(x);

}

It can also slow down some programs a lot.

Agreed. This also makes less sense without origins - do you think we shall hide it behind track-origins>0 ?

LGTM
Consider extending the test with another alloca which does not participate in any untraceable lifetimes, but has to be poisoned in entry block anyway.

Please test the case when alloca can not be found.
See https://bugs.llvm.org/show_bug.cgi?id=41481 for the reference.

This is very similar to GetUnderlyingObject, but it also handles PHIs, has a cache, but does not do InstructionSimplify and does not have a lookup limit.
It would be nice to merge the two.

Is this meant as a test-only thing?
I don't think we want sanitizer Printf anywhere close to production.

LGTM

Yes, seems pretty obvious.
LGTM.

LGTM

I think I prefer the cmake flag, too.
It's not unthinkable that hwasan might stop providing operator new and friends in the future. I was a bit surprised that we even do it now in COMPILER_RT_HWASAN_WITH_INTERCEPTORS=OFF configuration - but it looks like we are keeping it.
Anyway, lets not hardcode this decision.

LGTM

To see this problem, move your build directory to a full path starting with "/c".

As far as I can see, "unit" tests in lib/msan/tests also use the freshly built compiler through msan_compile / clang_compile cmake macros. Otherwise this CL would break everyone's builds.

Reverted in r356001.

In D58858#1425740, @Hahnfeld wrote:

I'm running that configuration for years and it always worked. Do you have a change at hand that did such compiler change?

This is expected to break. I'm surprised it did not break earlier - we often do a compiler change and corresponding integration tests in compiler-rt as a single commit, or two consecutive commits.

Could this be done with a target("sse4.2") function attribute instead of cmake conditions?

LGTM, good job!

you have a test file under lib/Target/AArch64.
Is it intentional? I don't think it does anything...

LGTM

This needs a compiler-rt test.

rebase

And D58755 to make sure this never happens again.

r355064 should do this.

Thanks, I'll fix it in a moment.

This bot seems unhappy:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/6651