Page MenuHomePhabricator

[CUDA][HIP] Defer overloading resolution diagnostics for host device functions
ClosedPublic

Authored by yaxunl on Jul 22 2020, 2:26 PM.

Details

Summary

In CUDA/HIP a function may become implicit host device function by
pragma or constexpr. A host device function is checked in both
host and device compilation. However it may be emitted only
on host or device side, therefore the diagnostics should be
deferred until it is known to be emitted.

Currently clang is only able to defer certain diagnostics. This causes
false alarms and limits the usefulness of host device functions.

This patch lets clang defer all overloading resolution diagnostics for host device functions.

An option -fgpu-defer-diag is added to control this behavior. By default
it is off.

It is NFC for other languages.

Diff Detail

Event Timeline

yaxunl created this revision.Jul 22 2020, 2:26 PM
yaxunl updated this revision to Diff 279950.Jul 22 2020, 2:57 PM

update for depending patch change

tra added a subscriber: rsmith.Jul 22 2020, 3:19 PM

It's an interesting idea and it may be needed to handle wider range of implicitly-HD functions.
However it's likely to have interesting consequences, not all of them desirable.
It may be worth considering hiding the new behavior behind a flag, make it optional at first, give it some soak time and only then make it the default.
Summoning @rsmith for the big picture input.

One side effect of this change is that we'll probably stop producing diagnostics for the code that is known to be wrong, but happens to be unused.

E.g.

__host__ __device__ static void hd() {
   no_such_type_t t;
}

We obviously can never compile this function on either side of the compilation and clang currently does diagnose it on both sides.
However, if all diagnostics in HD functions are postponed until codegen, this error will go unreported.

What if I have a syntax error in a HD function? I'd still want it to be diagnosed.
It's going to be interesting to see how it affects parsing subsequent code.
E.g https://godbolt.org/z/1vfPcc -- clang complains about the error in innocent due to an error in hd. If all diags issues in hd are postponed and the user only sees error: function definition is not allowed here, it will be rather confusing, because the innocent itself is perfectly fine.

Also, this patch may need more eyes on it. I'm sure there are more corner cases we may need to think about.
E.g. how would it affect SFINAE? Will it allow some things to succeed where they would've failed previously? If so, is it always the right thing to do?

We'll certainly want to have more tests that cover the errors that we still want to be produced.

In D84364#2168036, @tra wrote:

E.g.

__host__ __device__ static void hd() {
   no_such_type_t t;
}

We obviously can never compile this function on either side of the compilation and clang currently does diagnose it on both sides.
However, if all diagnostics in HD functions are postponed until codegen, this error will go unreported.

I am not certain but I could imagine a scenario in which problematic code would trigger visible changes to the program behavior w/o an error ever being emitted. That seems really undesirable.

yaxunl updated this revision to Diff 280013.Jul 22 2020, 8:13 PM
yaxunl edited the summary of this revision. (Show Details)

Added option -fgpu-defer-diag to control this new behavior. By default it is off.
Added test for syntax error.

In D84364#2168036, @tra wrote:

One side effect of this change is that we'll probably stop producing diagnostics for the code that is known to be wrong, but happens to be unused.

E.g.

__host__ __device__ static void hd() {
   no_such_type_t t;
}

We obviously can never compile this function on either side of the compilation and clang currently does diagnose it on both sides.
However, if all diagnostics in HD functions are postponed until codegen, this error will go unreported.

What if I have a syntax error in a HD function? I'd still want it to be diagnosed.
It's going to be interesting to see how it affects parsing subsequent code.
E.g https://godbolt.org/z/1vfPcc -- clang complains about the error in innocent due to an error in hd. If all diags issues in hd are postponed and the user only sees error: function definition is not allowed here, it will be rather confusing, because the innocent itself is perfectly fine.

A diagnostic will be deferred only if clang successfully parsed a function declaration and the current context is a function declaration.

In the above situation, clang fails to parse the function and the current context is not a function, therefore the error is emitted immediately, like before.

I have added a lit test for such situation.

Also, this patch may need more eyes on it. I'm sure there are more corner cases we may need to think about.
E.g. how would it affect SFINAE? Will it allow some things to succeed where they would've failed previously? If so, is it always the right thing to do?

We only defer diagnostics happen inside a host device function. My guess is that SFINAE will work as before since it happens not in a function scope, therefore it is not deferred. I will add some tests.

I'd like to clarify a little bit about deferring an error.

First it is localized to a function. If an error causes a function not parsed completely, it will be emitted immediately.

So if an error is deferred, it means clang at least parses that function containing it.

Second, if an entity caused an error which is deferred, it does not mean clang thinks gee, let's defer it, and thinks now we do not have error here. It is more like OK here is an error and we know it. We just save that message somewhere and do not print it out for now. clang knows that error happened and propagates the error status the same way as non-deferred diagnostics inside that function. In a sense, the deferred diagnostic and immediate diagnostic does not differ much.

Another thing we can do is to limit the diagnostic messages that can be deferred. For example, we only defer semantic diagnostics, or overloading resolution related diagnostics. According to previous experience, what bothers us most are the diagnostics triggered by the differences in function overloading on device and host sides. If a diagnostic tends to happen on both sides, e.g. syntax error, there is less value to defer it.

FWIW, OpenMP does also defer some diagnostics. It feels like a mess we can't avoid. That means, I think there is merit in generalizing this. I haven't reviewed this in any detail though.

yaxunl updated this revision to Diff 280102.Jul 23 2020, 7:06 AM

added lit test for SFINAE

yaxunl updated this revision to Diff 280144.Jul 23 2020, 8:42 AM

update the lit test for SFINAE. make sure substitution failure does not incur error msg if there is valid substitution.

Since template is not allowed in local class, there is no need for test SFINAE inside host device function.

tra added a comment.Jul 23 2020, 11:12 AM

I'm going to try the patch on our CUDA code and see how it fares. Stay tuned.

tra added a comment.Jul 23 2020, 2:31 PM
In D84364#2170244, @tra wrote:

I'm going to try the patch on our CUDA code and see how it fares. Stay tuned.

The patch works well enough to build TensorFlow which is a good sign that existing working code should be OK -- we're making HD checks less strict, so already working code should not be affected.

The remaining concern is whether we're going to unintentionally allow something we should not have. Let me see if I can come up with some examples, in addition to the hdf_not_called()one I've commented on in the test file.

clang/test/SemaCUDA/deferred-all.cu
12–18 ↗(On Diff #280144)

I think we do need diagnostics in this scenario, regardless of whether the function is called or not.
We would have emitted it for a regular inline function and I believe it should be the case here, too.

44 ↗(On Diff #280144)

Nit: I'd rename type -> isA which would make its use in sfinae() more obvious.

yaxunl marked 4 inline comments as done.Jul 27 2020, 8:58 AM
In D84364#2170769, @tra wrote:
In D84364#2170244, @tra wrote:

I'm going to try the patch on our CUDA code and see how it fares. Stay tuned.

The patch works well enough to build TensorFlow which is a good sign that existing working code should be OK -- we're making HD checks less strict, so already working code should not be affected.

The remaining concern is whether we're going to unintentionally allow something we should not have. Let me see if I can come up with some examples, in addition to the hdf_not_called()one I've commented on in the test file.

I added a Deferrable bit to the diagnostics which can be specified in td files. This can be added to individual diagnostic defs or added to a bunch of diagnostic defs all together.

This field is used to control whether a diagnostic message can be deferred.

For now I enabled this bit for the overloading resolution diagnostics since these have been seen as false alarms in host device functions. We could let more diagnostics be deferrable if we see it is necessary.

clang/test/SemaCUDA/deferred-all.cu
12–18 ↗(On Diff #280144)

Limited deferred diagnostics to a set of specified diagnostics in .td files.

44 ↗(On Diff #280144)

done

yaxunl updated this revision to Diff 280938.Jul 27 2020, 9:06 AM
yaxunl marked 2 inline comments as done.
yaxunl retitled this revision from [CUDA][HIP] Defer all diagnostics for host device functions to [CUDA][HIP] Defer overloading resolution diagnostics for host device functions.
yaxunl edited the summary of this revision. (Show Details)

Added Deferrable bit to diagnostics to control whether a diagnostic can be deferred.

yaxunl added a comment.Aug 6 2020, 3:08 PM

I just saw bugzilla bug https://bugs.llvm.org/show_bug.cgi?id=46922

my patch https://reviews.llvm.org/D77954 is supposed to fix this issue. However since implicit host device functions often cause overloading resolution diagnostics on the device side which are not deferred, my patch caused regressions and was reverted several times. Currently it was still reverted.

I think to fix this issue we need to make overloading resolution diagnostics deferrable.

tra added a comment.Aug 6 2020, 3:38 PM

I added a Deferrable bit to the diagnostics which can be specified in td files. This can be added to individual diagnostic defs or added to a bunch of diagnostic defs all together.

This field is used to control whether a diagnostic message can be deferred.

This may be a case of "too much, but not enough". It will be unnecessary for most of the diagnostics we have. Overload resolution is likely to be the primary beneficiary, inline asm and exceptions may be two other classes, but I can't think of anything else ATM.
At the same time it may not be enough, because we also need to take into account where and when particular diagnostic is emitted. I.e. the same diagnostic may need to be postponed when we emit it from CUDA code, yet we may want to *not* postpone it if it's in the code which has nothing to do with CUDA. E.g. C++ code which has oveloading-related error in an inline function which would not be codegen'ed. I would expect such error to be reported as it would be if the same function was compiled in plain C++ mode.

For now I enabled this bit for the overloading resolution diagnostics since these have been seen as false alarms in host device functions. We could let more diagnostics be deferrable if we see it is necessary.

I just saw bugzilla bug https://bugs.llvm.org/show_bug.cgi?id=46922
my patch https://reviews.llvm.org/D77954 is supposed to fix this issue. However since implicit host device functions often cause overloading resolution diagnostics on the device side which are not deferred, my patch caused regressions and was reverted several times. Currently it was still reverted.

I think to fix this issue we need to make overloading resolution diagnostics deferrable.

I'm missing something here. How would deferred diagnostics help with the issue in the bug 46922? The HD function there is codegen'ed on both sides, so the only difference postponing would make is that we'd emit the diagnostic a bit later.
Do you mean that postponed diags patch is not the fix, but rather a prerequisite for the overload resolution changes patch?

yaxunl updated this revision to Diff 289814.Sep 3 2020, 2:44 PM

Defer overload resolution diags only if there are wrong-sided candidates.

yaxunl added a comment.Sep 3 2020, 2:52 PM
In D84364#2201336, @tra wrote:

I added a Deferrable bit to the diagnostics which can be specified in td files. This can be added to individual diagnostic defs or added to a bunch of diagnostic defs all together.

This field is used to control whether a diagnostic message can be deferred.

This may be a case of "too much, but not enough". It will be unnecessary for most of the diagnostics we have. Overload resolution is likely to be the primary beneficiary, inline asm and exceptions may be two other classes, but I can't think of anything else ATM.
At the same time it may not be enough, because we also need to take into account where and when particular diagnostic is emitted. I.e. the same diagnostic may need to be postponed when we emit it from CUDA code, yet we may want to *not* postpone it if it's in the code which has nothing to do with CUDA. E.g. C++ code which has oveloading-related error in an inline function which would not be codegen'ed. I would expect such error to be reported as it would be if the same function was compiled in plain C++ mode.

I added a heuristics based rule for deferring overloading resolution related diagnostics. Basically clang will check if there are wrong-sided candidates when an overloading resolution error happens. This seems to be able to capture most of the host-ness related diagnostics which we want to defer whereas without affecting the diagnostics that are unrelated to host-ness.

For now I enabled this bit for the overloading resolution diagnostics since these have been seen as false alarms in host device functions. We could let more diagnostics be deferrable if we see it is necessary.

I just saw bugzilla bug https://bugs.llvm.org/show_bug.cgi?id=46922
my patch https://reviews.llvm.org/D77954 is supposed to fix this issue. However since implicit host device functions often cause overloading resolution diagnostics on the device side which are not deferred, my patch caused regressions and was reverted several times. Currently it was still reverted.

I think to fix this issue we need to make overloading resolution diagnostics deferrable.

I'm missing something here. How would deferred diagnostics help with the issue in the bug 46922? The HD function there is codegen'ed on both sides, so the only difference postponing would make is that we'd emit the diagnostic a bit later.
Do you mean that postponed diags patch is not the fix, but rather a prerequisite for the overload resolution changes patch?

Right. We need to favor same sided candidates for host device functions to fix that issue, the obstacle to implement the correct host/device based overloading resolution is that implicit host device function causes diagnostics in device compilation, which should be deferred but currently are not. With this patch we may be able to fix the overloading resolution issue properly.

tra added a comment.Sep 3 2020, 4:41 PM

LGTM.

Nice!

To sum it up -- the patch introduces -fgpu-defer-diag flag which allows deferring overload resolution diagnostics, if overload set included candidates from both sides.

We may be deferring cases when we don't have to (e.g. df()->()callee2() should've errored out right away, even during host compilation, as there's no way it could ever be valid), but this approach is a good starting point. It affects only the interesting subset of diags, is not enabled by default, and can be refined further, if necessary.

clang/include/clang/Basic/LangOptions.def
244

The description does not seem to reflect reality. IIUIC only overload-related diagnostic messages will be deferred.

tra accepted this revision.Sep 3 2020, 4:41 PM
This revision is now accepted and ready to land.Sep 3 2020, 4:41 PM
yaxunl marked an inline comment as done.Sep 3 2020, 7:32 PM
In D84364#2255572, @tra wrote:

LGTM.

Nice!

To sum it up -- the patch introduces -fgpu-defer-diag flag which allows deferring overload resolution diagnostics, if overload set included candidates from both sides.

We may be deferring cases when we don't have to (e.g. df()->()callee2() should've errored out right away, even during host compilation, as there's no way it could ever be valid), but this approach is a good starting point. It affects only the interesting subset of diags, is not enabled by default, and can be refined further, if necessary.

Thanks Artem. Would you please also review https://reviews.llvm.org/D84362 since this patch depends on that. Thanks.

clang/include/clang/Basic/LangOptions.def
244

will fix when committing

This revision was automatically updated to reflect the committed changes.
yaxunl marked an inline comment as done.
Herald added a project: Restricted Project. · View Herald TranscriptSep 17 2020, 8:32 AM
hctim added a subscriber: hctim.Sep 17 2020, 10:12 AM

Looks like this patch broke the MSan buildbots, PTAL (repro instructions https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild):

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/46239/steps/check-clang%20msan/logs/stdio

FAIL: Clang :: SemaCUDA/deferred-oeverload.cu (11308 of 26387)
******************** TEST 'Clang :: SemaCUDA/deferred-oeverload.cu' FAILED ********************
Script:
--
: 'RUN: at line 1';   /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/clang/12.0.0/include -nostdsysteminc -fcuda-is-device -fsyntax-only -verify=dev,com /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/test/SemaCUDA/deferred-oeverload.cu    -std=c++11 -fgpu-defer-diag
: 'RUN: at line 3';   /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/clang/12.0.0/include -nostdsysteminc -fsyntax-only -verify=host,com /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/test/SemaCUDA/deferred-oeverload.cu    -std=c++11 -fgpu-defer-diag
--
Exit Code: 77

Command Output (stderr):
--
==41680==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0xddfbf73 in clang::OverloadCandidateSet::CompleteCandidates(clang::Sema&, clang::OverloadCandidateDisplayKind, llvm::ArrayRef<clang::Expr*>, clang::SourceLocation, llvm::function_ref<bool (clang::OverloadCandidate&)>) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:11484:9
    #1 0xde4e7ca in clang::OverloadCandidateSet::NoteCandidates(std::__1::pair<clang::SourceLocation, clang::PartialDiagnostic>, clang::Sema&, clang::OverloadCandidateDisplayKind, llvm::ArrayRef<clang::Expr*>, llvm::StringRef, clang::SourceLocation, llvm::function_ref<bool (clang::OverloadCandidate&)>) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:11529:9
    #2 0xde6316f in FinishOverloadedCallExpr(clang::Sema&, clang::Scope*, clang::Expr*, clang::UnresolvedLookupExpr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, clang::OverloadCandidateSet*, clang::OverloadCandidate**, clang::OverloadingResult, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:12959:19
    #3 0xde6296b in clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*, clang::UnresolvedLookupExpr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, bool, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:13032:10
    #4 0xd4e126b in clang::Sema::BuildCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaExpr.cpp:6378:16
    #5 0xd53e073 in clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaExpr.cpp:6275:7
    #6 0xcaa957f in clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult<clang::Expr*, true>) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:2066:23
    #7 0xcaaf03e in clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser::TypeCastState, bool, bool*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:1811:9
    #8 0xcaa5f3e in clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, clang::Parser::TypeCastState, bool, bool*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:681:20
    #9 0xcaa15f3 in clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:173:20
    #10 0xcaa13ad in clang::Parser::ParseExpression(clang::Parser::TypeCastState) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:124:18
    #11 0xcbc8288 in clang::Parser::ParseExprStatement(clang::Parser::ParsedStmtContext) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:446:19
    #12 0xcbc2183 in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:234:12
    #13 0xcbc119d in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:106:20
    #14 0xcbdd830 in clang::Parser::ParseCompoundStatementBody(bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:1098:11
    #15 0xcbe0b67 in clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:2259:21
    #16 0xc9c26d4 in clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:1375:10
    #17 0xca17b5b in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:1924:27
    #18 0xc9bf6ee in clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:1135:10
    #19 0xc9bde93 in clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:1151:12
    #20 0xc9bb56b in clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:971:12
    #21 0xc9b5d18 in clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:716:12
    #22 0xc9a49cf in clang::ParseAST(clang::Sema&, bool, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseAST.cpp:158:20
    #23 0x8de7de0 in clang::FrontendAction::Execute() /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Frontend/FrontendAction.cpp:950:8
    #24 0x8ce176d in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:984:33
    #25 0x905ccb9 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:278:25
    #26 0xb9bc9d in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/tools/driver/cc1_main.cpp:240:15
    #27 0xb93aa6 in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/tools/driver/driver.cpp:330:12
    #28 0xb928ad in main /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/tools/driver/driver.cpp:407:12
    #29 0x7f3d1d0dc09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    #30 0xb15209 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/clang-12+0xb15209)

SUMMARY: MemorySanitizer: use-of-uninitialized-value /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:11484:9 in clang::OverloadCandidateSet::CompleteCandidates(clang::Sema&, clang::OverloadCandidateDisplayKind, llvm::ArrayRef<clang::Expr*>, clang::SourceLocation, llvm::function_ref<bool (clang::OverloadCandidate&)>)
Exiting

--

********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
********************
Failed Tests (1):
  Clang :: SemaCUDA/deferred-oeverload.cu

Looks like this patch broke the MSan buildbots, PTAL (repro instructions https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild):

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/46239/steps/check-clang%20msan/logs/stdio

FAIL: Clang :: SemaCUDA/deferred-oeverload.cu (11308 of 26387)
******************** TEST 'Clang :: SemaCUDA/deferred-oeverload.cu' FAILED ********************
Script:
--
: 'RUN: at line 1';   /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/clang/12.0.0/include -nostdsysteminc -fcuda-is-device -fsyntax-only -verify=dev,com /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/test/SemaCUDA/deferred-oeverload.cu    -std=c++11 -fgpu-defer-diag
: 'RUN: at line 3';   /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/clang/12.0.0/include -nostdsysteminc -fsyntax-only -verify=host,com /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/test/SemaCUDA/deferred-oeverload.cu    -std=c++11 -fgpu-defer-diag
--
Exit Code: 77

Command Output (stderr):
--
==41680==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0xddfbf73 in clang::OverloadCandidateSet::CompleteCandidates(clang::Sema&, clang::OverloadCandidateDisplayKind, llvm::ArrayRef<clang::Expr*>, clang::SourceLocation, llvm::function_ref<bool (clang::OverloadCandidate&)>) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:11484:9
    #1 0xde4e7ca in clang::OverloadCandidateSet::NoteCandidates(std::__1::pair<clang::SourceLocation, clang::PartialDiagnostic>, clang::Sema&, clang::OverloadCandidateDisplayKind, llvm::ArrayRef<clang::Expr*>, llvm::StringRef, clang::SourceLocation, llvm::function_ref<bool (clang::OverloadCandidate&)>) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:11529:9
    #2 0xde6316f in FinishOverloadedCallExpr(clang::Sema&, clang::Scope*, clang::Expr*, clang::UnresolvedLookupExpr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, clang::OverloadCandidateSet*, clang::OverloadCandidate**, clang::OverloadingResult, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:12959:19
    #3 0xde6296b in clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*, clang::UnresolvedLookupExpr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, bool, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:13032:10
    #4 0xd4e126b in clang::Sema::BuildCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaExpr.cpp:6378:16
    #5 0xd53e073 in clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaExpr.cpp:6275:7
    #6 0xcaa957f in clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult<clang::Expr*, true>) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:2066:23
    #7 0xcaaf03e in clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser::TypeCastState, bool, bool*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:1811:9
    #8 0xcaa5f3e in clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, clang::Parser::TypeCastState, bool, bool*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:681:20
    #9 0xcaa15f3 in clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:173:20
    #10 0xcaa13ad in clang::Parser::ParseExpression(clang::Parser::TypeCastState) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:124:18
    #11 0xcbc8288 in clang::Parser::ParseExprStatement(clang::Parser::ParsedStmtContext) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:446:19
    #12 0xcbc2183 in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:234:12
    #13 0xcbc119d in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:106:20
    #14 0xcbdd830 in clang::Parser::ParseCompoundStatementBody(bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:1098:11
    #15 0xcbe0b67 in clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:2259:21
    #16 0xc9c26d4 in clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:1375:10
    #17 0xca17b5b in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:1924:27
    #18 0xc9bf6ee in clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:1135:10
    #19 0xc9bde93 in clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:1151:12
    #20 0xc9bb56b in clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:971:12
    #21 0xc9b5d18 in clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:716:12
    #22 0xc9a49cf in clang::ParseAST(clang::Sema&, bool, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseAST.cpp:158:20
    #23 0x8de7de0 in clang::FrontendAction::Execute() /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Frontend/FrontendAction.cpp:950:8
    #24 0x8ce176d in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:984:33
    #25 0x905ccb9 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:278:25
    #26 0xb9bc9d in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/tools/driver/cc1_main.cpp:240:15
    #27 0xb93aa6 in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/tools/driver/driver.cpp:330:12
    #28 0xb928ad in main /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/tools/driver/driver.cpp:407:12
    #29 0x7f3d1d0dc09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    #30 0xb15209 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/clang-12+0xb15209)

SUMMARY: MemorySanitizer: use-of-uninitialized-value /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:11484:9 in clang::OverloadCandidateSet::CompleteCandidates(clang::Sema&, clang::OverloadCandidateDisplayKind, llvm::ArrayRef<clang::Expr*>, clang::SourceLocation, llvm::function_ref<bool (clang::OverloadCandidate&)>)
Exiting

--

********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
********************
Failed Tests (1):
  Clang :: SemaCUDA/deferred-oeverload.cu

Thanks. Reverted it. I will fix it.

Looks like this patch broke the MSan buildbots, PTAL (repro instructions https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild):

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/46239/steps/check-clang%20msan/logs/stdio

FAIL: Clang :: SemaCUDA/deferred-oeverload.cu (11308 of 26387)
******************** TEST 'Clang :: SemaCUDA/deferred-oeverload.cu' FAILED ********************
Script:
--
: 'RUN: at line 1';   /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/clang/12.0.0/include -nostdsysteminc -fcuda-is-device -fsyntax-only -verify=dev,com /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/test/SemaCUDA/deferred-oeverload.cu    -std=c++11 -fgpu-defer-diag
: 'RUN: at line 3';   /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/clang/12.0.0/include -nostdsysteminc -fsyntax-only -verify=host,com /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/test/SemaCUDA/deferred-oeverload.cu    -std=c++11 -fgpu-defer-diag
--
Exit Code: 77

Command Output (stderr):
--
==41680==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0xddfbf73 in clang::OverloadCandidateSet::CompleteCandidates(clang::Sema&, clang::OverloadCandidateDisplayKind, llvm::ArrayRef<clang::Expr*>, clang::SourceLocation, llvm::function_ref<bool (clang::OverloadCandidate&)>) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:11484:9
    #1 0xde4e7ca in clang::OverloadCandidateSet::NoteCandidates(std::__1::pair<clang::SourceLocation, clang::PartialDiagnostic>, clang::Sema&, clang::OverloadCandidateDisplayKind, llvm::ArrayRef<clang::Expr*>, llvm::StringRef, clang::SourceLocation, llvm::function_ref<bool (clang::OverloadCandidate&)>) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:11529:9
    #2 0xde6316f in FinishOverloadedCallExpr(clang::Sema&, clang::Scope*, clang::Expr*, clang::UnresolvedLookupExpr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, clang::OverloadCandidateSet*, clang::OverloadCandidate**, clang::OverloadingResult, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:12959:19
    #3 0xde6296b in clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*, clang::UnresolvedLookupExpr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, bool, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:13032:10
    #4 0xd4e126b in clang::Sema::BuildCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaExpr.cpp:6378:16
    #5 0xd53e073 in clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::Expr*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaExpr.cpp:6275:7
    #6 0xcaa957f in clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult<clang::Expr*, true>) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:2066:23
    #7 0xcaaf03e in clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser::TypeCastState, bool, bool*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:1811:9
    #8 0xcaa5f3e in clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, clang::Parser::TypeCastState, bool, bool*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:681:20
    #9 0xcaa15f3 in clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:173:20
    #10 0xcaa13ad in clang::Parser::ParseExpression(clang::Parser::TypeCastState) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:124:18
    #11 0xcbc8288 in clang::Parser::ParseExprStatement(clang::Parser::ParsedStmtContext) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:446:19
    #12 0xcbc2183 in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:234:12
    #13 0xcbc119d in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:106:20
    #14 0xcbdd830 in clang::Parser::ParseCompoundStatementBody(bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:1098:11
    #15 0xcbe0b67 in clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:2259:21
    #16 0xc9c26d4 in clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:1375:10
    #17 0xca17b5b in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:1924:27
    #18 0xc9bf6ee in clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:1135:10
    #19 0xc9bde93 in clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:1151:12
    #20 0xc9bb56b in clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:971:12
    #21 0xc9b5d18 in clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/Parser.cpp:716:12
    #22 0xc9a49cf in clang::ParseAST(clang::Sema&, bool, bool) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseAST.cpp:158:20
    #23 0x8de7de0 in clang::FrontendAction::Execute() /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Frontend/FrontendAction.cpp:950:8
    #24 0x8ce176d in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:984:33
    #25 0x905ccb9 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:278:25
    #26 0xb9bc9d in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/tools/driver/cc1_main.cpp:240:15
    #27 0xb93aa6 in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/tools/driver/driver.cpp:330:12
    #28 0xb928ad in main /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/tools/driver/driver.cpp:407:12
    #29 0x7f3d1d0dc09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    #30 0xb15209 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/clang-12+0xb15209)

SUMMARY: MemorySanitizer: use-of-uninitialized-value /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:11484:9 in clang::OverloadCandidateSet::CompleteCandidates(clang::Sema&, clang::OverloadCandidateDisplayKind, llvm::ArrayRef<clang::Expr*>, clang::SourceLocation, llvm::function_ref<bool (clang::OverloadCandidate&)>)
Exiting

--

********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
********************
Failed Tests (1):
  Clang :: SemaCUDA/deferred-oeverload.cu

I am trying to reproduce this issue by building clang with -fsanitize=memory. However I got memory sanitizer failures with llvm-tblgen:

[422/2415] Building Options.inc...
FAILED: cd /home/yaxunl/git/llvm/build-msan && /home/yaxunl/git/llvm/build-msan/bin/llvm-tblgen -gen-opt-parser-defs -I /home/yaxunl/git/llvm/llvm/tools/clang/include/clang/Driver -I/home/yaxunl/git/llvm/llvm/tools/clang/include -I/home/yaxunl/git/llvm/build-msan/tools/clang/include -I/home/yaxunl/git/llvm/build-msan/include -I/home/yaxunl/git/llvm/llvm/include /home/yaxunl/git/llvm/llvm/tools/clang/include/clang/Driver/Options.td --write-if-changed -o tools/clang/include/clang/Driver/Options.inc -d tools/clang/include/clang/Driver/Options.inc.d

30130==WARNING: MemorySanitizer: use-of-uninitialized-value

#0 0xbdfe6a in find /home/yaxunl/git/llvm/llvm/include/llvm/ADT/StringRef.h:320:11
#1 0xbdfe6a in llvm::StringRef::split(llvm::SmallVectorImpl<llvm::StringRef>&, char, int, bool) const /home/yaxunl/git/llvm/llvm/lib/Support/StringRef.cpp:344:20
#2 0xbee57c in llvm::Triple::Triple(llvm::Twine const&) /home/yaxunl/git/llvm/llvm/lib/Support/Triple.cpp:747:19
#3 0xc29d25 in llvm::sys::getProcessTriple() /home/yaxunl/git/llvm/llvm/lib/Support/Host.cpp:1597:10
#4 0xb8704e in ParseCommandLineOptions /home/yaxunl/git/llvm/llvm/lib/Support/CommandLine.cpp:1337:17
#5 0xb8704e in llvm::cl::ParseCommandLineOptions(int, char const* const*, llvm::StringRef, llvm::raw_ostream*, char const*, bool) /home/yaxunl/git/llvm/llvm/lib/Support/CommandLine.cpp:1312:24
#6 0xb27a53 in main /home/yaxunl/git/llvm/llvm/utils/TableGen/TableGen.cpp:280:3
#7 0x7f4569cc883f in __libc_start_main /build/glibc-e6zv40/glibc-2.23/csu/../csu/libc-start.c:291
#8 0x42a7a8 in _start (/mnt/sdc1/home/yaxunl/git/llvm/build-msan/bin/llvm-tblgen+0x42a7a8)

Is this some known issue? Thanks.

Not a known issue - no, but MSan doesn't play nice with uninistrumented libraries (including things like libcxx) - and so it can be tricky to ensure your build is properly sanitized, which is why I'd recommend the build script :).

Not a known issue - no, but MSan doesn't play nice with uninistrumented libraries (including things like libcxx) - and so it can be tricky to ensure your build is properly sanitized, which is why I'd recommend the build script :).

Thanks for the suggestion. I reproduced the issue with the build script and fixed it.